1) I want to see files open for write have nothing to do with it. Unix
open/close is not a transaction, it's just a connection. Some applications
manage to use open/close as a transaction, but we're seeing less and less
of that as more sophisticated facilities for transactions become available.
How many times have we all been frustrated trying to remount read only when
some log file that hasn't been written to for hours is open for write?
A file write is in progress when a write() system call hasn't returned, not
when the file is open for write.
Someone who wants to coordinate his mounts with the applications that use
them should use an external locking scheme.
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).
3) A system call to put a mount into readonly state should not return until
all writes in progress have completed out to the medium, and the cache is
clean. It should sync the cache, of course, and do whatever closing of the
filesystem an unmount would do. Any attempt to start a new write during
this wait (which constitutes another mount state) should fail.
I was thinking an option to fail immediately instead of waiting for writes
to complete might be useful, but then I couldn't think of any write in
progress that would take enough time to make it worthwhile. As long as any
new system call counts as a new write.
The same thinking applies to an option to kill writes in progress without
waiting. Unless maybe it means to skip the cache synchronization.
4) I don't think it has any semantic relevance, but as part of this, I'd
also like to see the FS implementation stop considering read only mount
status to be a file permission issue. (Today, it does in some places, but
doesn't in others).
I don't know enough about how filesystem drivers use the "readonly" state
today for damage control when errors happen, so I won't give an opinion on
that. But it sounds like it would probably be that quiescing state I
mentioned in (3), not the readonly state I mentioned in (2).
-
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 Aug 31 2001 - 21:00:36 EST