On Tue, Nov 26, 2013 at 08:06:36PM -0700, Chris Murphy wrote: > > 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.
I'm not commenting on what fstab does or does not do - I commented on the incorrect assertion that was made about fsck.xfs being a no-op. > 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. fstab expects that if it is asked for the filesystem to be checked and the device is missing, then fsck.<foo> will return an error because the device is missing and it could not be checked.... > > 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? No, I didn't say that. I just explained that things can go wrong if you don't detect certain types of errors in fsck.<foo> when it is called from fstab processing. What I am implying here is that we cannot prevent users from setting passno to 1 or 2 in /etc/fstab. We have no control over that and so asserting that "we don't need a fsck.btrfs because we can set passno to 0" is invalid. IOWs, fsck.btrfs needs to be present and it needs to behave correctly in these cases.... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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
