On Nov 26, 2013, at 5:51 PM, Dave Chinner <da...@fromorbit.com> wrote:
> On Mon, Nov 25, 2013 at 11:40:49PM -0700, Chris Murphy wrote: >> Hi, >> >> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful >> of threads indicating some idea of having it just do a no-op like >> fsck.xfs does, but then also the idea that /etc/fstab should >> correctly set fs_passno to 0 instead of such trickery. > > You're missing a key thing that fsck.xfs does that fstab expects to > work - it fails with an error if the device is missing. If the > device is present, then fsck.xfs returns success. The description of fs_passno taken literally doesn't account for this explanation. It just says if fs_passno is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked. So the fstab expects (or is it systemd or an fsck instance spawned by systemd?) this device present/missing flag to occur is a convention? Or by design? Seems goofy. > We did this because people were having problems when devices took a > long time to instantiate (e.g. SAN, iscsi and other remote devices) > and the 'device exists' check prevents /etc/fstab trying to mount > the filesystems before they are present and then throwing a hissy > fit…. OK so you're saying you'd want rootfs on XFS to have its fstab entry retain an fs_passno of 1? Or you'd rather see the process responsible for making sure that the claimed rootfs device is made available before throwing hissy fits when it can't be found? Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
