On Jul 3, 2014, at 6:23 AM, Tom Gundersen <t...@jklm.no> wrote: > Hm, the only way this would get re-fscked in the system is if it is > explicitly configured to be in /etc/fstab... Shouldn't we just give > people what they ask for?
In practice, often the wrong thing is happening these days. Users and distros appear to routinely not understand what fs_passno should be set to, and set it incorrectly. Even man 5 fstab has wrong information "The root filesystem should be specified with a fs_passno of 1". And on Fedora Rawhide it looks like either a systemd unit or the initramfs is causing fsck to be run on XFS and Btrfs file systems, even when fs_passno is 0. What about a new fs_passno value of -1 that means "use default for this file system type", and systemd spawns fsck based on the recommendation of that file system's devs? For FAT, ext, and HFS+ clearly the default is to fsck. For XFS, Btrfs, ZFS, NTFS, the default is not to fsck. > Otherwise passno= for the rootfs would have > no effect at all in this setup (the rootfs is fscked unconditionally > in the initrd regardless of what /etc/fstab says (obviously)). Well it doesn't hurt to fsck e.g. XFS, but it's effectively a no op so it's superfluous, just like it is for Btrs and ZFS. The fstab fs_passno and fsck at boot time paradigm has changed since its inception. And I think systemd systems can do this smarter while still being generic about it. The use case and mount point really doesn't matter, it's the file system type that dictates whether fsck ought to be run. Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
