Re: nested file system types

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Mon, 16 Mar 2009 08:08:54 -0400
Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

> 
> "Toru Nishimura" <locore64%alkyltechnology.com@localhost> writes:
> 
> > Hi,
> >
> >> I'm working on mount_vnd(8).  It's pretty
> >> straight-forward; the catch is that I need to be able to specify
> >> the file system type that's layered on top of vnd.
> >
> > I'm skeptic about inventing mount_vnd(8), however, want to wait
> > for the output.  If going that way, please consider how /etc/fstab
> > should be sanely extended for multiple stacked FS.  One of
> > fundamental issues we have is a vague distinction (or confusion)
> > among "filesystem" and "how-to-stack-each-other."
> 
> I don't understand from the name what mount_vnd is supposed to do.
> There is now a three step process:
> 
>   find a free vnd somehow
>   vnconfig (make vnd associated with a file)
>   mount the vnd
> 
> so what I think would be cool is extending
> 
>   mount_lfs /dev/rwd0e /mnt
> 
> to
> 
>   mount_lfs vnd:/home/gdt/lfs.image /mnt
> 
> where mount_msdos grabs a vnd number and does vnconfig, and umount
              ^^^^^
I assume you meant lfs there.

> will do vnconfig -u and release.
> 
This is more or less it.  I want the moral equivalent of ad's
translation:

        mount -t cd9660 image.iso /mnt

but as he notes, that involves "a lot of tedious work".  Worse yet,
it's kernel work, and if we have the ability to do it in userland I
don't see why we should add more complexity to the kernel.

The rationale for the functionality is simple: this is a very common use
(arguably, the most common use) of vnds; why not make it easy?

One option is to change mount to detect that the first positional
parameter is a file rather than a device.  I'm very reluctant to do
that, because if you make a typing mistake or get the order wrong
you're in big trouble.  Instead, I was originally thinking of something
like this:

        mount_vnd -T lfs [-r] [-z] file mountpoint

Finding a free vnd is unpleasant but not difficult.  If nothing else,
the code can iterate, looking for a free vnd.  locore64 said that vnd
is now a cloning pseudo-device; is that accessible at user level, or
will it take device driver changes?

Unmount requires new something-or-other, since the umount command
doesn't seem to look for umount_fstype, and I'd need that (or changes
to umount(8)) to unconfigure the vnd.  Conceptually, though, either
choice works.

I haven't figured out what to do about disk labels.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb