Date: Thu, 20 May 1999 00:07:26 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@rush.net (Alfred Perlstein) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: ufs/ffs interaction? Message-ID: <199905200007.RAA14098@usr04.primenet.com> In-Reply-To: <Pine.BSF.3.96.990519182408.26546U-100000@cygnus.rush.net> from "Alfred Perlstein" at May 19, 99 06:45:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Does the code in src/sys/ufs/ufs/ layer itself on top of all > filesystems? ie, UFS == naming scheme wereas msdosfs,ffs,ntfs > are just called by the ufs code? > > for instance in src/sys/ufs/ufs/ufs_vnops.c line 1628: > > error = VOP_READ(ap->a_vp, uio, 0, ap->a_cred); > > depending on the filesystem associated with the vnode, we can call the > > msdosfs_read(ap) (line 545) > > function? It's true that whatever FS is associated with the vnode will have it's VOP_READ vector called; this could be a different FS, or the the FS itself. The code path you took to get in to that point, however, is really the determining factor. The UFS code provides directory management for the MFS, FFS, LFS, and EXT2FS file systems. In general, the layout and flexname implementation that these FS's have is similar enough that they can share code. The implementation of naming, seperate from a flat numeric block namespace, or a flat numeric inode namespace representing a variable granularity block store, etc., is actually logically more seperate than the current relationship between the UFS and other code would have you believe. There are a number of layering issues where the interfaces are not sufficiently abstract to allow you to implement a totally seperate repacement for UFS, but these are rather trivial to clean up (but without something much more complicated that requires this cleanup, you are unlikely to be able to defend the changes against claims that you are merely editorializing, and that your changes are unnecessary). About three years ago, I did the cleanups and implemented a btree for storing directory contents (I replaced the UFS layer). That change itself speeds up directory lookups significantly, but is most valuable when you have file name globbing in the kernel instead of user space, since it allows you to push only matching data back across the user/kernel boundary. For a NetWare server (as an example), where the client will ask first for directories, then for files, this significantly reduces the work in the seperate request necessitated first and second pass over the data. For the first pass, you push back only directories, and for the second, you push back only files. This results in a factor of three speedup with a directory containing a 5:1 file:directory ratio, with an average of 20uS per user/kernel boundary crossing, and more if the globbing eliminates some files or directories. In any case, you should view the UFS layer as implementing directory management above several layers, and the fact that it is being directly referenced by the FFS code as a design compromise having to do with dynamic linking capabilities at the time it was implemented. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905200007.RAA14098>