From owner-freebsd-hackers Sun Dec 14 22:48:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA27078 for hackers-outgoing; Sun, 14 Dec 1997 22:48:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA27061 for ; Sun, 14 Dec 1997 22:48:24 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id RAA01358; Mon, 15 Dec 1997 17:12:41 +1030 (CST) Message-Id: <199712150642.RAA01358@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) In-reply-to: Your message of "Mon, 15 Dec 1997 06:34:44 -0000." <199712150634.XAA25793@usr09.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Dec 1997 17:12:41 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > 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