[lkml]   [1998]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: autofs vs. Sun automount -- new fs proposal

On 15 Dec 1998, Stefan Monnier wrote:

> >>>>> "Richard" == Richard Gooch <> 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.

> 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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:46    [W:0.057 / U:68.352 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site