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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
