Date: Fri, 5 Nov 1999 13:43:09 -0500 (EST) From: Erez Zadok <ezk@cs.columbia.edu> To: Jan Pechanec <pechy@hp735.cvut.cz> Cc: Erez Zadok <ezk@cs.columbia.edu>, Robert Watson <robert+freebsd@cyrus.watson.org>, freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? Message-ID: <199911051843.NAA21856@shekel.mcl.cs.columbia.edu> In-Reply-To: Your message of "Fri, 05 Nov 1999 15:23:22 %2B0100." <Pine.SGI.4.05.9911051518180.10246-100000@akat.civ.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.SGI.4.05.9911051518180.10246-100000@akat.civ.cvut.cz>, Jan Pechanec writes: > On Thu, 28 Oct 1999, Erez Zadok wrote: > > Hi, > > I think that it is a bit different. What Robert is hacking is > a filesystem where in-vfs-not-experienced programmer can see how vfs > is working. I have just read some of your papers, Erez, and I think > that wrapfs wants me not to bother with something like vfs (just > encode and decode routines). The encode and decode routines that wrapfs exports are an API that greatly simplifies two difficult tasks: (1) modifying file names (e.g., translating b/t unix and 8.3 names) (2) modifying file data (e.g., encryption) Every other task you want to accomplish in wrapfs, you do it right in the actual f/s routines, right in the code itself. For example, if you wanted to add acl support (as I've done w/ a trivial aclfs based on wrapfs), you add the right code in lookup(). If you want to create an unrmfs (another prototype I've got), you add it in unlink(). If you wish, you can also touch the read/write/getpage/putpage routines directly and not use the encode/decode API functions. But you'll find that there's a substantial amount of support code needed to deal with data pages, locking, and a lot more stuff around it. All of this is detailed in my Usenix 99 paper. > I think that Robert's effort is very useful, I wanted myself > to write somethink like this (purpose: to learn and _touch_ vfs > interface). Robert, do you carry on or not? I commend you, but don't be surprised if what you'll produce in the end will be almost identical to wrapfs in functionality. It many ways, wrapfs is "stupid", b/c it only provides a thin layer that passes all VOPs to the layer below it, while maintaining semantics. Wrapfs does not do much more than that. That's why I'm telling you now that your stupidfs may wind up being very similar to wrapfs. You cannot get stacking functionality with much less than wrapfs does. If you actually intend to modify the VFS, and add new VOPs, that'll be neat too. But I think you'll find it a bit difficult to get VFS changes merged into the main source tree... :-) And if you will change the VFS, you'll find that your stupidfs does more than, and is "smarter" than wrapfs. You cannot introduce new VOPs w/o changing the VFS, and if you change the VFS, you must make sure that other (native) file systems do something reasonable with these new VOPs. > -- > Jan PECHANEC (mailto:pechy@hp735.cvut.cz) Computing Center CTU (Zikova 4, > Praha 6, 166 35, Czech Republic) http://www.civ.cvut.cz, tel: +420 2 2435 > 2969, http://pechy.civ.cvut.cz Jan et al. I'm not trying to "hawk my merchandise" on you, but rather to save you a great deal of effort repeating that which has been done before. I've created and released my wrapfs templates so that others could build on them, and create hopefully really useful (even commercial) file systems. It may sound corny, but I hope that my work will revitalize the stagnating field of stackable file systems research. You may save a lot of time, and still be able to learn much, by starting with my wrapfs code, and modifying it to your needs. I will be happy to help you in any way I can. Cheers, Erez. 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?199911051843.NAA21856>