Date: Tue, 9 Nov 1999 09:53:07 +0100 From: Jan Pechanec <pechy@hp735.cvut.cz> To: freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? Message-ID: <Pine.SGI.4.05.9911090948500.5402-100000@akat.civ.cvut.cz> In-Reply-To: <199911051914.OAA23367@shekel.mcl.cs.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 5 Nov 1999, Erez Zadok wrote: >In message <Pine.BSF.3.96.991105095504.51562B-100000@fledge.watson.org>, Robert Watson writes: >[...] >> Because wrapfs doesn't work in 3.3-RELEASE yet, and because of the reasons >> you mention, I decided to keep working on a stupidfs :-). > >I'll be updating wrapfs for 3.3 once I return from LISA. With luck, it'll >work again before you return from Albuquerque. > >> That is, that I >> don't want to add functionality to an existing file system by stacking, >> but rather to have a new simple file system that I can modify the >> semantics of in ways not encouarged by the stacking of file systems. > >If I understand you right (maybe I didn't), there are two ways to do that: > Hello, how I understand is, eg.: let's write a simple kernel fs for new developers to learn. The fs can have just 2 directories, no tree structures, max. 10 files in the directory. It will be simple so that a programmer who has little experience in writing fs's can easily look at it and understand. There is no idea about stacking or about using existing fs's together with stupid-fs. But maybe I didn't understand right :-). Therefore I think that Erez and Robert don't ,,compete'', wrapfs and stupidfs will be written for different purpose. cheers, Jan. >(1) Create a simple *native* (disk based?) file system template from which > you can possibly create new file systems that put data on disks and > floppies, right? In theory, one should be able to create msdosfs and > ffs from such a template. In practice, there are numerous details to > work out, that getting something barely working for a "stuipid" template > will require substantial effort. Such a template would be very useful > if it will have these two characteristics: (a) be small and simple, and > (b) require little modification to create file systems such as msdosfs > and ffs. I believe that with current OS technology, it is impossible to > get both 'a' and 'b' done. > >(2) If what you want is a file system that can work with other file systems, > then you're essentially asking for stacking. Yes stacking f/s usually > have to maintain VFS semantics, so that a layer is kept independent from > other layers, either above or below it. It is possible, however, for a > stackable f/s to violate this priniciple; for example, you can muck with > direct disk blocks and inode blocks from a stackable f/s. It's not > something I'd recommend, but it is possible. > >> I am >> currently traveling (IETF next week, Active Network conference in >> Alberquerque the week after) so won't get back to my development machines >> for about two weeks. After that time, I hope to get a stupidfs >> implementation to the point where it might be useful for others to see, so >> I'll put it online. As I mentioned before, the goal is to have a really >> simple file system with no backing store, appropriate for use when >> experimenting with new VOPs, etc, etc. > >I'd be very interested in seeing this. I would also suggest that before you >dive into coding, you write out a detailed design, and post it to this list, >so we could all comment on it. > >Note that extensible VFSs have been the expressed desire of stackable file >systems from the very early days. In order for me to support file system >extensibilty without changing the OS or other file systems, I had to give up >the idea of creating new VOPs. That is, you cannot add new vops using >wrapfs; you could create new ioctls, however, which are the poor man's >extensible model. IOW, if you created an infrastructure that can extend the >VFS, you'll have something that wrapfs cannot do --- something that people >have been asking for some time. (So don't call it "stuipid" :-) > >If you haven't already, you should read up on all of the classic stacking >papers first, from Rosenthal, Skinner & Wong, Heidemann, Popek, etc. Then >you might look into papers on Spring, BSD's Unionfs, and the HURD. All of >these talk about mechanisms for VFS extensibility that would be useful for >you. > >> It won't be fully functioning (for >> example, I probably won't even bother to implement symlinks) but it will >> be *simple*, meaning it can be modifed easily. It will also be separable >> into an entirely separate module, unlike UFS which has fingers everywhere, >> so it can easily be loaded and unloaded on demand during development. >> >> I wouldn't encourage anyone to use it in production--it will make a fair >> amount of use of kernel memory, as it won't back to a process--but for >> development it should be useful. > >I think you have to be very careful about your implementation. You cannot >encourage people to use something in PRODUCTION that has not been thoroughly >tested, and esp. if it's missing functionality. If you want your f/s to be >useful, make sure it works with existing VFSs and existing file systems. At >the very least, make sure it won't damage people's installations. It would >be nice if "all" it did was _add_ new VOPs, while keeping existing ones >unchanged. > >I'm speaking from experience here. I've developed wrapfs on solaris, >freebsd, and linux. In the early days, I've dealt with bugs that easily >corrupted active memory and resulted in total corruption of system and boot >partitions, to a point where a reinstallation was required. After a few >frustrating reinstallations, I wound up setting up automatic OS installation >systems (network-based booting, installing off of an auxiliary disk, even >using identical disks and dd'ing a good copy onto a trashed one). > >> Robert N M Watson >> >> robert@fledge.watson.org http://www.watson.org/~robert/ >> PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 >> TIS Labs at Network Associates, Safeport Network Services > >Good luck. Let me know if I can help. > >Erez. > -- Jan PECHANEC (mailto:pechy@hp735.cvut.cz) Computing Center CTU (Zikova 4, Praha 6, 166 35, Czech Republic) www.civ.cvut.cz, pechy.civ.cvut.cz, tel: +420 2 24352969 (fax: 24310271) 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.SGI.4.05.9911090948500.5402-100000>