On Nov 27, 2013, at 12:52 PM, Lennart Poettering <lenn...@poettering.net> wrote:
> On Wed, 27.11.13 12:15, Chris Murphy (li...@colorremedies.com) wrote: > >> On Nov 27, 2013, at 4:53 AM, Kay Sievers <k...@vrfy.org> wrote: >>> >>> Right, it should not set 1 for btrfs. >> >> Since it can be mounted rw from the get go, is it going to far to plan >> for one day dropping the initial ro mount, remount rw sequence? > > Hmm, no, not really. If no initrd is used it's already bad enough that > we run fsck while we have the file system mounted, but it would be even > worse if we'd write to the file system. Such concern doesn't seem indicated for btrfs. It checks and fixes itself at rw mount time, which either works or fails, and if it fails the fs doesn't mount. > The recommended logic is: use an initrd, and fsck the rootfs before > mounting, and do so writable. The legacy logic is: use no initrd, and > let the kernel mount read-only, then file system check, then remount > writable. Well the recommended logic for btrfs differs substantially. The use of btrfsck --repair is dead last on the list of things to try, it's definitely not the first like is accepted with other file systems. If rw fails, then systemd should remount with option 'recovery'. If that fails, and it's a multiple device volume, then remount with option 'degraded'. And if that also fails, then remount with 'ro,recovery' - and maybe (?) we should go to emergency.target at that point rather than fully boot. This sort of conditional remounting attempts isn't something fstab can do. > > Or actaully, it's even more complex than that: the remount step after > fsck does more than just mount writable, it will actually apply the > mount options in /etc/fstab to the root file system, whatever those > settings might be. Writability is just one of the. Understood, but if default mount options are wisely chosen by btrfs devs, then fstab is obviated for most use cases. The most typical btrfs mount option needed is specifying a subvolume for rootfs, which must be done with rootflags=subvol= anyway because only putting it in fstab is too late. And for other use cases, like compression, that can be done with either rootflags= or fstab. Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
