Re: autofs vs. Sun automount -- new fs proposal

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On 15 Dec 1998, Stefan Monnier wrote:
> 
> > >>>>> "Richard" == Richard Gooch <[e-mail]> writes:
> > > 1)  the sledgehammer approach, which doesn't affect the VFS
> > > 2)  the clean approach which requires VFS changes.
> > 
> > Having no idea what this option 2 would look like (though the little bit
> > of understanding I have leads me to believe that option 2 deserves the
> > mention `efficient' rather than `clean' (changing the VFS in order to provide
> > another filesystem hardly sounds `clean' to me)), I have a question:
> 
> No. VFS misses a generic mechanism for stacked filesystems. lofs is not
> the only consumer for that - actually umsdos and hfs are trying to do the
> same. It's a VFS issue and it's done in several kernels (*BSD, for
> one^Wthree). General idea behind it being that each layer can decide
> whether to serve operation, decline it or pass to underlying one(s). There
> is a support for lightweight layers (e.g. UID translation). There is
> unionfs. BTW, Richard's devfs would also fit nice into this beast.

Agreed. With stackfs I could get access to underlying inodes virtually
for free, which would be nice, as it would allow me to pull out the
device permissions from the underlying disc-based FS. And push them
back when a change is made.
Actually, I think it's a VFS issue, not Just Another FS[tm].

> > With option 1, I'm pretty sure it's not hard to provide varying mount options,
> > of which `ro' would be the most useful (I like to use for the same reason that
> > I like to make some of my files read-only (it doesn't prevent me from modifying
> > them, but it forces me to take extra steps to do it)).  How about option 2 ?
> > I understand that providing read-only LoFS mounts is low priority enough
> > that if it's not trivial it won't be done, hence my question.
> 	And problem with implementing that being? 

The "clean" (or "fast", however you want to look at it) solution is to
let the dentry layer do the work for you. For that you would need
aliasing support for all dentries. Offhand, I don't see how you'd
support a read-only option with a pure dentry scheme. In fact, I see
the read-only requirement as a strong reason for doing it the "hard"
way (i.e. not enhancing the VFS interface). A read-only lofs is great
for securing ftp and tftp servers.

				Regards,

					Richard....