Date: Mon, 15 Dec 1997 17:12:41 +1030 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712150642.RAA01358@word.smith.net.au> In-Reply-To: Your message of "Mon, 15 Dec 1997 06:34:44 -0000." <199712150634.XAA25793@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Consider the FFS directory management code. It has knowledge of > > > physical blocks. In fact, it can not easily handle a directory > > > block that is not exactly a physical block size. The current code > > > can not be broken across block I/O's, nor can it handle partial > > > block I/O's well (there are a number of failure modes). > > > > This sounds like a fault in the FFS design. Do you know of any work > > that deals with this? > > I dealt with this when I changed the DIRBLKSZ from 512 to 1024 in the > Windows95 port of FFS that Artisoft did. I had to do this to support > a maximally-sized Unicode file name in the Unicode namespace required > by Windows 95's IFS. Ok. By this you confess that you understand the issues, and you have dealt with them comprehensively before. I do hope that Artisoft let you take your notes with you... 8) > > > For you to be able to fit a maximally-sized file name in a single > > > directory block means your directory block must be over 512 bytes > > > in length. > > > > Would you suggest upping the "fundamental" system blocksize? How would > > FFS cope in the face of 2k blocks? > > It would have to set the DIRBLKSZ to the minimum of the amount required > and the physical block size, and deal with agregating multiple blocks. Pardon my ignorance, but what's the issue with aggregating blocks? I presume that the directory code reads/writes in multiples of DIRBLKSZ > This has implications for the atomicity of the directory operations, > since metadata updates must be synchronus. It's messy without changes > to namei() and the opacity of a cn_pnbuf structure (which must be opaque > in order to be able to serve multiple namespaces at the same time... not > just because making it opaque renders the interface reflexive. How is an update of a group of blocks any less atomic than the update of a single block? Is this only an issue in the light of fragmentation of a directory on a non-DIRBLKSZ multiple boundary? > > > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > > > are not constrained to start at an even offset from the start of the > > > disk, only from an even cylinder boundry. > > > > In the light of the nonexistence of "cylinders" in the proposed model, > > it strikes me that this becomes an issue of synthesising a conforming > > pseudo-geometry at filesystem creation time, and little more. > > Compatability is likely an issue there. > > Page alignment must equal 1k block alignment for the 0th of 4 blocks; > alternately, access will be... uh, slow. I think you've left out enough context there that I can't approach any of that. Unless you are referring to mmap() on such files. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712150642.RAA01358>