lkml.org 
[lkml]   [2001]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFD] readonly/read-write semantics


On Sat, 1 Sep 2001, Ingo Oeser wrote:

> On Sat, Sep 01, 2001 at 12:23:05AM -0400, Alexander Viro wrote:
> > > 2) I'd like to see a readonly mount state defined as "the filesystem will
> > > not change. Period." Not for system calls in progress, not for cache
> > > synchronization, not to set an "unmounted" flag, not for writes that are
> > > queued in the device driver or device. (That last one may stretch
> > > feasability, but it's a worthy goal anyway).
> >
> > It doesn't work. Think of r/o mounting of remote filesystem. Do you
> > suggest that it should make it impossible to change from other clients?
>
> It's sufficient for local file systems. Or see it this way: The
> machine, that mounted it r/o will NOT write to it until it is
> mounted r/w again.

That's _also_ not true for remote filesystems. We can mount the same
filesystem over NFS again without unmounting the old instance. Always
could.

IMO a part of the problem is that we are mixing "I'm not asking that
to be writable" with "I won't let you write". The former belongs
to the mounting side, the latter - to filesystem.

Notice that setups along the lines "mount /dev/sda5 read-only on /home/jail/pub
and read-write on /home/ftp/pub" are not that unreasonable, so even for local
filesystems it might make sense.

IOW, I suspect that right solution would have two separate layers -
* does anyone get write access under that mountpoint? (VFS)
* is this fs asked to handle write access and had it agreed with that?
(filesystem)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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