Date: Wed, 17 Jun 1998 20:09:48 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: "Alton, Matthew" <Matthew.Alton@anheuser-busch.com> Cc: "'FreeBSD-fs@FreeBSD.ORG'" <FreeBSD-fs@FreeBSD.ORG>, "Smallie, Scott" <Scott.Smallie@anheuser-busch.com>, FreeBSD Hackers <Hackers@FreeBSD.ORG> Subject: Re: Filesystem Development Toolkit Message-ID: <Pine.SV4.3.95.980617190738.4908A-100000@parkplace.cet.co.jp> In-Reply-To: <31B3F0BF1C40D11192A700805FD48BF9017765D7@STLABCEXG011>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew, The project sounds interesting. You might want to refer to John Heidemann's work done while he was at UCLA. You can find his pages at I think http://www.isi.edu/~johnh. His approach is radically different and potentially a lot less work for future FS implementors. You could define a standard vop interface and map it into FreeBSD and the vop layers of other Unix implementations. Basically it allows you to leverage off of existing code. In FreeBSD a partially implemented framework exists, but it needs to be cleaned up. There are 2 major problems with it now: 1) There are ref counting and locking layering violations in the code. I've cleaned these up for everything except vop_rename, vop_mknod, and vop_symlink so far. 2) There is no object coherence management done. This is a more serious problem that is inherent in any stacked design where you want to cache objects, data, and attributes in different layers that represent a file. This will require taking a hard look at the top half of the kernel code where calls are made to things like vop_rdwr, mmap, vop_{put|get}pages and the implementation themselves to properly design it. In a layered environment you need to make sure that operations are either done on the same vnode of a file or you need a cache_mgr to manage coherence between the cached objects hanging off of all the vnodes that represent the file. One reason that I'd like to see a user-space layer implemented is that it would represent an extra requirement in the design of the solution to the problems in 2) above. i.e. Instead of putting in VM calls here and there you would be forced to think of a cleaner solution, otherwise you will have to implement a lot of weird system calls to emulate those VM calls. If you implemented a cache_mgr then you could reduce the number of system calls you would need to implement and use in your user-land emulation of the kernel APIs. With a cache_mgr implementation, vop_putpages and vop_getpages would take 2 vnode pointers. One would be a caching vp and the other would be the paging vp and these could potentially be in different layers of the stack. The cache_mgr would ensure that the correct vps are passed to the operations. For example, if you implemented a compression or encryption layer on top of ufs, you would likely want the clear text cached for performance, but you would want to ensure that the ufs pager were used to actually write to the media. Then at night when a backup is running against the compressed files, the ufs layer would be the caching layer. I wish I had the time to work on something like this, but I don't. As far as people that can contribute to this the following list is what I can come up with off the top of my head. Poul Henning-Kamp, Julian Elisher, David Greenman, Bruce Evans, Peter Wemm, Doug Rabson, Tor Egge, Luoqi Chen, and Simon Shapiro. I mention Simon Shapiro because he has been working on a DLM and many of the concepts are similar but generalized to not just locks, but also data pages and file attributes. It's interesting to note that John Heidemann's experimental versions did not include locks and was not distributed. It just used the existing vnode locking implementation and interfaced with other distributed protocols such as NFS, etc. Of course, if some lurker out there were to take on this challenge that would be pretty cool too. Regards, Mike Hancock 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?Pine.SV4.3.95.980617190738.4908A-100000>