On Feb 5, 2014, at 4:24 AM, Jorge Fábregas <jorge.fabregas@xxxxxxxxx> wrote: > On 02/03/2014 03:16 PM, Chris Murphy wrote: >> It seems to me that there will be some error message in the log >> as the (stale) fstab tries to do a rw mount of a different subvol on >> top of the one specified by rootflags=. Or maybe it succeeds silently, >> I haven't recently tested this scenario. > > Yes, I wondered about this. I even questioned the purpose of specifying > the root filesystem in fstab since it is already present as a kernel > parameter in GRUB. Is this the flow of events? > > - kernel mounts read-only the root filesystem specified as kernel > parameter in GRUB > - init/systemd reads fstab and remounts root-filesystem read-write > (along with specified mount options) Yes. It's a throwback from when file systems needed an fsck to even determine if they had a problem, and then to fix them, because they didn't have journals. man fsck.xfs It's not really doing an fsck at all. The unattended repair from crash or unclean mount is done at mount time by the XFS kernel code replaying the journal. If that doesn't work, then user involvement is needed because chances are it's a hardware problem: bad sector read errors, flaky controller cable, bad RAM, a LUN has died. In which case there may be real file system damage, but that's what xfs_repair is for. First, every physical device that makes up the file system needs to be present and working, and then probably best to do a dry run through with xfs_repair -n. But even if you don't, if you haven't first tried to mount XFS, xfs_repair will say sorry, do not collect $200, go back and mount the file system so the journal can be replayed, unmount, and then run me. Btrfs is similar in concept but there are a lot more things to try before running btrfs repair (which is what btrfsck points to these days). There isn't even an fsck.btrfs placeholder. Before running btrfs repair, one should try mount option recovery. If it's multiple devices, then try mount option degraded. And btrfs repair should be preceded with btrfs check and posting those results to linux-btrfs@. The repair tool is practically a last resort and sometimes still can make things worse. I'm not sure where ext4 repair code in the kernel is at, but like XFS it has a journal and is designed to mostly repair itself from crashes and unclean shutdowns simply by mounting the file system. It may be there's still useful unattended repair code in user space fsck.ext4. So yeah, we probably could safely mount a Btrfs rootfs rw from the get go, and apply mount options with rootflags= as a boot parameter, and forego an fstab entry. I've done this quite a bit as a test so I know it works. Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
