Date: Sun, 18 Apr 1999 11:57:14 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: peter@netplex.com.au (Peter Wemm) Cc: dillon@apollo.backplane.com, dyson@iquest.net, dg@root.com, hackers@freebsd.org Subject: Re: Directories not VMIO cached at all! Message-ID: <199904181657.LAA18643@dyson.iquest.net> In-Reply-To: <19990418164232.4DC7C1F2A@spinner.netplex.com.au> from Peter Wemm at "Apr 19, 99 00:42:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> "John S. Dyson" wrote: > > > :You are right about VDIR's not being B_VMIO. That was a decision made ear > ly > > > :on when the vfs_bio code was not trustworthy :-). It is okay, and advanta > geous > > > :to cache VDIR's with merged cache. > [..] > > The only advantage of getting rid of B_MALLOC would be to totally relax > > the amount of memory used for caching directories. The disadvantage > > is the potentially gross amount of internal fragmentation of memory. > > > > Perhaps before getting rid of B_MALLOC, take a look at the standard > > mix of directory sizes (don't just look at news servers.) If there is an > > extreme bias towards 512 or 2048, then you might consider keeping B_MALLOC. > > Would small block devices/filesystems likely be affected? (ie: msdos, > ext2fs etc) > Special dispensation is given to those filesystems... All blocks are laid out into merged cache pages. The locality of reference associated with typical filesystem usage argues against the overhead of the fragmentation. In the case of directories, the fragmentation is due to the allocation unit size of the merged cache (1 PAGE), and the size of the directory typically being < 1PAGE. Of course, it is advantageous to have block sized directory chunks for disk filesystem consistancy reasons. (I don't really know if it is so valuable now.) For small block filesystems, it would be wasteful (or would cause incoherence) to either use B_MALLOC buffers, or allocate each block as a portion of a page. This is where alot of the complexity of the current caching scheme comes into play. Also, NFS is a weird monster in it's own right. Frankly, NFS is a candidate to make into a true merged filesystem (bypassing the buffer cache entirely), and FFS is such a candidate because of it being so common. Since the need for backwards compatibility with the old BSD style buffer cache isn't really needed any more (softupdates is likely the only important development that legacy support is needed), I strongly suggest "fixing" the commonly used filesystems to bypass the majority of the vfs_bio complexity now. (That was in my plans.) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904181657.LAA18643>