On Tue, May 19, 2015 at 12:02:31PM -0600, Chris Murphy wrote: > On Tue, May 19, 2015 at 1:24 AM, Russell Coker <[email protected]> wrote: > > Do you have a reference for fsck on a ro mounted ext4 filesystem being > > dangerous? The standard behavior of Linux systems has been to fsck a ro > > mounted ext* root filesystem since long before an initrd was invented. > > Actually, slight confusion. XFS has a repair dangerously mode > explicitly for repairing ro mounted XFS file systems. The man page for > e2fsck says it's unsafe to fsck a mounted fs. It doesn't explicitly > distinguish between ro and rw mounts, but from this list I've learned > ro mounts aren't guaranteed to be ro, even if they should be ro. The > e2fsck man page says even if it's safe, it's unreliable. > > Anyway, it seems worse to me to have a system where you have to ro > mount a file system that you suspect might be inconsistent so that the > fsck binary can be read and then operated on that same file system. > Ancient madness.
The ancient method was to run fsck on a RO mounted root filesystem, and if fsck corrected errors, immediately reboot to avoid corruption. Hopefully the second boot gets past the root filesystem, which is theoretically now clean. This fails badly if the fsck needs to touch metadata required for the fsck or reboot, leading to failure of the init scripts (there is no systemd in the ancient method) followed by potentially massive root filesystem corruption. That sounds bad, but in practical terms there were so many failure modes in the ancient method that there's no point in choosing just one to get upset over. ;) These days we have initramfs, which can treat the root filesystem like any other filesystem, and check it fully offline before mounting it. Put dropbear on the initramfs and the filesystem can be interactively repaired over the network before mounting it too. Alas, I don't know of any distros that handle root mounts correctly. I always have to roll my own initramfs to get it right. >:-/ > > -- > Chris Murphy > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
