Eric Sandeen wrote:
except in the case of a journaling filesystem, where the journal in
theory obviates the need for a fsck. (yes, I know... fsck still has a
place...) But, fsck is largely meaningless until the journal has been
recovered anyway (fs can only be consistent if it includes uncommited
transactions in the journal), so isn't this new territory?
In a way, yes, this is new territory, but not entirely. It is merely an
extension of the existing system, and in the existing system the ro flag
clearly meant do not write to the disk. You don't extend an existing
system by breaking old expectations.
I'm admittedly playing devil's advocate here :) but what, in the
historical non-journalled filesystem case, would be writing to the
device anyway, if all IO from the vfs were stopped? Without the
journal, isn't vfs-ro the same as bdev-ro, largely?
Yes, they were the same, and that is my point: users got used to using
ro to indicate they did not want the block device written to, and were
doing this long before there was a read only flag on the block device
itself. Excepting journal playback from this breaks user expectation
and leads to data loss.
As a counter example, if you had a filesystem which saves it's last
mount time in the superblock; should a ro mount not update that time?
(perhaps not, depending on how that timestamp was intended to be used.)
This is another good example arguing against writing to the disk. Ext2
would write to the super block to mark the volume as dirty and update
the mount count used to decide when it was time for a fsck. It did not
do this if mounted read only because it understood that the meaning of
the ro flag was not to write to the disk. Likewise, it did not update
file's atime. If ro just meant "don't let me write to files" then the
atime would be updated even when mounted read only.
You might not damage the underlying filesystem, but you could sure go
off in the weeds trying to read it, if you stumbled upon some
half-updated metadata... so while it may be safe for the filesystem, I'm
not convinced that it's safe for the host reading the filesystem.
And this is exactly what you get without journals. You mount a damaged
filesystem read only, you take what you can get. You might get bad
data, or fail to open or read certain files or parts of files, but you
knew for sure that you wouldn't cause any more damage to the data on
disk, and you could run a fsck or defrag or partimage or anything else
to read and/or modify the disk.
but it's already changed, and has been in linux since ext3 came on the
scene. mount -o ro -does- replay the journal. Surely readonly does not
imply that we want a corrupted filesystem if it was not cleanly shut
down. I suppose there is a place for the argument that a readonly mount
of a journaled filesystem -should- present a recovered filesystem to the
user, without actually recovering the log to disk. I guess to me, it
hardly seems worth the effort, as the precedent is long set for doing
recovery on a read-only mount.
Just because a bug has been around for a long time does not mean it is
not a bug. In the pre-journal world, if you mounted a dirty filesystem
read only you expected the possibility of errors reading it. Why should
that expectation not hold true with journals? It might be nice to do
the journal playback in ram or otherwise without writing to the disk,
but as far as the user setting the ro flag cares, they just want you not
to update the disk and if there are inconsistencies that cause errors,
then you need to fsck or mount rw.
-
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]
