Messages in this thread | | | Subject | Re: [RFD] readonly/read-write semantics | From | "Bryan Henderson" <> | Date | Fri, 31 Aug 2001 17:38:19 -0700 |
| |
>> 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.
- 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/
| |