Date: Fri, 5 Nov 1999 14:14:49 -0500 (EST) From: Erez Zadok <ezk@cs.columbia.edu> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Jan Pechanec <pechy@hp735.cvut.cz>, Erez Zadok <ezk@cs.columbia.edu>, freebsd-fs@FreeBSD.ORG Subject: Re: stupidfs - easily extensible test file systems? Message-ID: <199911051914.OAA23367@shekel.mcl.cs.columbia.edu> In-Reply-To: Your message of "Fri, 05 Nov 1999 09:59:56 EST." <Pine.BSF.3.96.991105095504.51562B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911051914.OAA23367>