Date: Mon, 15 Dec 1997 06:34:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, mike@smith.net.au, bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712150634.XAA25793@usr09.primenet.com> In-Reply-To: <199712140222.MAA04796@word.smith.net.au> from "Mike Smith" at Dec 14, 97 12:52:07 pm
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. > > 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. 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. It's the sweater where you pul one thread... > > 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. > > Ah, brave new world, that has such thing in't. 8-). > > Yeah. I bet the old farts are saying "good thing it's them windbags > discussin' this, if'n it were someone prone to doin' stuff we'd be in > serious shit, eh boys"? 8) Well, you have commit privs, right? I wouldn't be adverse to having a little code committed. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712150634.XAA25793>