On Saturday 01 September 2001 09:44 am, Alexander Viro wrote:
> 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.
It's really a band-aid, I seriously doubt anybody is going to claim that
it's "perfect".
The state that he (and I for that matter) want is "This is mounted, we
can read from it, but under *NO CIRCUMSTANCES* will we change the
filesystem through this mount, ever."
In addition to the filesystem-stamping-its-foot situation, this could
help if someone is testing a new, potentialy unstable driver (filesystem
or block device) and wants to stop all writes IMMIEDIATELY so that they
can check the data present on that filesystem/device.
Again, this isn't perfect, but I think it would have many potential uses
(filesystem error would probably be the most useful application) and
really should have been implimented long ago.
-
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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:12 EST