[lkml]   [2001]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFD] readonly/read-write semantics
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:01    [W:0.295 / U:10.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site