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. On May 19, 2015 12:24:39 AM GMT+10:00, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >On Mon, May 18, 2015 at 3:22 AM, Roy Sigurd Karlsbakk ><roy@xxxxxxxxxxxxx> wrote: > >> >> I didn't run it. Some part of the Jessie startup did, and 1 minute >for just 6x8GB (not TB) seems a lot… > >Systemd issues a generic fsck for root fs, always, even for file >systems that don't have unattended fsck like XFS and btrfs. >Effectively the fs_passno field in fstab is ignored for root fs now. >In order to know what passno is set to required mounting root ro >first, and then executing fsck on an ro filesystem which even ext4 >considers dangerous. The fsck.xfs and fsck.btrfs don't really do >anything, if you read their man page you'll see that, but I think they >require all devices present for the fsck to return 0 and systemd to >continue with boot. So I'll bet that for some reason there's a delay >with the devices themselves, or with them all being discovered (by >udev?) and thus the systemd unit for root fs is hanging. > >If you're experiencing this 1 minute fsck on a non-root fs btrfs, then >that's a bug. There should be no fsck for btrfs, not even the faux >one. I'd check to make sure fs_passno is set to 0. If not, then I'd >look to the initramfs asking for the unnecessary fsck. -- Sent from my Samsung Galaxy Note 3 with K-9 Mail. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
