On Thu, Jan 04 2001 at 17:49:46 EST, Stephen C. Tweedie wrote:
> I will be adding support for virtual replay for root filesystems to
> act as a last-chance way of recovering if you really cannot write to
> the root, but journaling filesystems really do expect to be able to
> write to the media so I am not sure whether it makes sense to support
> this on non-root filesystems too.
> ...
> A root fs readonly mount is usually designed to prevent
> the filesystem from being stomped on during the initial boot so that
> fsck can run without the filesystem being volatile. That's the only
> reason for the readonly mount: to allow recovery before we enable
> writes. With ext3, that recovery is done in the kernel, so doing that
> recovery during mount makes perfect sense even if the user is mounting
> root readonly.
Apologies for a belated follow-up, but the coverage of this thread in
Kernel Traffic caught my eye. I understand that both ext3fs and
reiserfs will try to fix corrupt filesystems (or at least filesystems
with unprocessed log entries) in-place even if they're mounted
read-only. Clearly, virtual replay means more work, but -- just for
fun -- here are some cases in which it might matter:
1. You want the disk image untouched for forensic analysis or data
recovery.
2. You don't trust the disk to do writes properly.
3. You don't trust the driver to do writes properly.
4. You want to test a newer or unstable FS implementation w/ option to
go back to the older one.
5. You're sharing the disk via:
VMWare (multiple OS instances on 1 computer)
passive backplane (multiple computers on 1 bus)
PCI bridge (multiple computers w/ connected buses)
SCSI/FC/FireWire (multiple computers sharing device)
The merit of #5 is reduced but not quite obviated by the fact that
it's generally unsafe to share a disk if even one party is writing to
it. (It might barely be possible do safe one-writer/many-reader disk
sharing using a phase-tree-like FS, but as interesting projects go, it
probably rivals heterogeneous SMP in perversity.)
Come to think of it, you could probably use loopback to insulate the
disk from writes in all these cases. Hmm.
Please CC me on any follow-ups.
--Jeff
Jeff writes:
> I understand that both ext3fs and
> reiserfs will try to fix corrupt filesystems (or at least filesystems
> with unprocessed log entries) in-place even if they're mounted
> read-only. Clearly, virtual replay means more work, but -- just for
> fun -- here are some cases in which it might matter:
>
> 1. You want the disk image untouched for forensic analysis or data
> recovery.
> 2. You don't trust the disk to do writes properly.
> 3. You don't trust the driver to do writes properly.
> 4. You want to test a newer or unstable FS implementation w/ option to
> go back to the older one.
Excluding the root fs (which probably isn't involved in these sorts of
things anyways), you can always turn off the "RECOVERY" flag on the
filesystem and mount ext3 as ext2, which will not do any recovery.
> 5. You're sharing the disk via:
> VMWare (multiple OS instances on 1 computer)
> passive backplane (multiple computers on 1 bus)
> PCI bridge (multiple computers w/ connected buses)
> SCSI/FC/FireWire (multiple computers sharing device)
>
> The merit of #5 is reduced but not quite obviated by the fact that
> it's generally unsafe to share a disk if even one party is writing to it.
Very true. Any changes made by the writer will not be noticed by the
reader if it has already cached those pages. Best to use a cluster
filesystem in all of these cases.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Hi!
> > I understand that both ext3fs and
> > reiserfs will try to fix corrupt filesystems (or at least filesystems
> > with unprocessed log entries) in-place even if they're mounted
> > read-only. Clearly, virtual replay means more work, but -- just for
> > fun -- here are some cases in which it might matter:
> >
> > 1. You want the disk image untouched for forensic analysis or data
> > recovery.
> > 2. You don't trust the disk to do writes properly.
> > 3. You don't trust the driver to do writes properly.
> > 4. You want to test a newer or unstable FS implementation w/ option to
> > go back to the older one.
>
> Excluding the root fs (which probably isn't involved in these sorts of
> things anyways), you can always turn off the "RECOVERY" flag on the
> filesystem and mount ext3 as ext2, which will not do any recovery.
_If_ you happen to realize that mount -o ro -t ext3 is not really read
only. sct know it may write to filesystem, now I know it; but I
believe that if you asked Joe Admin
"Linux writes to partition mounted read-only in some cases; is it a
bug?"
he would say
"YES!"
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]