Messages in this thread | | | From | Rob Landley <> | Subject | Re: Weirdness of "mount -o remount,rw" with write-protected floppy | Date | Fri, 28 Oct 2005 08:50:40 -0500 |
| |
On Friday 28 October 2005 08:15, Evgeny Stambulchik wrote: > Rob Landley wrote: > > It looks like one bug to me. The initial mount figures out that it's > > read only, and the actual writes fail correctly, but remount isn't > > checking for read only (and thus isn't failing). > > Right, but even after remount seemingly succeeds, an attempt to write to > an unwritable media should return an error nevertheless, as the > corresponding syscall should fail, obviously.
You're forgetting the cacheing (dentry and page caches).
We have a writeable filesystem mounted on a read-only block device. This is an impossible situation we should never have gotten into in the first place. That's the bug.
For performance reasons, the write stuffs the data into the page cache, and returns long before the system even attempts to write the data to disk. (Unless you mount the filesystem O_SYNC, which will kill performance.)
So the write happily succeeds, and by the time the later attempt to flush data to the underlying block device is made (by memory pressure or pdflush) there's nobody to report it to anymore. So it logs it.
Incidentally, this is why checking the return value of close() is silly. If you want to fsync the data, call fsync (which blocks until we've hit the disk and can thus report whether or not it actually made it). close() is just as cached as anything else, it updates an in-memory dentry that may nor may not successfully be flushed to disk later on, depending on whether or not the disk got hotplugged away out from under us before then...
Rob - 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/
| |