On Feb 5, 2014, at 4:24 AM, Jorge Fábregas <jorge.fabregas(a)gmail.com> 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