Re: [RFD] readonly/read-write semantics

["Bryan Henderson" <hbryan@us.ibm.com>]

>> 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...
>Thats what readonly does now, isn't it?

No, it's much more sloppy than that today.  The mount is slammed into the
readonly state and writes in progress continue to modify the filesystem
medium.  The remount system call does a weak check to see that there is no
writing going on before proceeding to set the readonly flag on.  A mkdir in
progress continues to complete.  A properly timed open for write could even
slip in.  The the opener can write away while the mount is in "readonly"
state.  And finally, Al points out that a filesystem driver that gets
scared by some consistency error may stamp its foot and declare "readonly"
state right under the nose of of open-for-write file descriptors, which
allow continued writing.

>But you want that also to be
>when the filesystem is writeable but not being written to at the
>moment, i.e. if its in a consistent state or "clean".

Well, no I don't.  That's another state.  And the mount goes in and out of
that state all the time without any help from us, so the only issue would
be detecting the state to make it useful.  I used to think Unix filesystems
always did that, but I don't seem to be able to get an ext2 filesystem
(mounted r/w) into no-fsck-required state without actually unmounting it.