From owner-freebsd-fs Fri Nov 5 11:15:54 1999 Delivered-To: freebsd-fs@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id 0435D14BE9 for ; Fri, 5 Nov 1999 11:15:49 -0800 (PST) (envelope-from ezk@shekel.mcl.cs.columbia.edu) Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA24974; Fri, 5 Nov 1999 14:14:50 -0500 (EST) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.1/8.9.1) id OAA23367; Fri, 5 Nov 1999 14:14:49 -0500 (EST) Date: Fri, 5 Nov 1999 14:14:49 -0500 (EST) Message-Id: <199911051914.OAA23367@shekel.mcl.cs.columbia.edu> X-Authentication-Warning: shekel.mcl.cs.columbia.edu: ezk set sender to ezk@shekel.mcl.cs.columbia.edu using -f From: Erez Zadok To: Robert Watson Cc: Jan Pechanec , Erez Zadok , freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? In-reply-to: Your message of "Fri, 05 Nov 1999 09:59:56 EST." Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , 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: (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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message