On Mon, Dec 2, 2013 at 12:01 AM, Dave Chinner <da...@fromorbit.com> wrote: > 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....
I actually think what btrfs is doing here is the more sensible thing (i.e., to not ship an fsck.btrfs), as it is a bit confusing to have a fsck.* that does not in fact do any filesystem checking. The way this stuff works under systemd is: * fsck is only ever called on a filesystem once the backing device has appeared (so under systemd, fsck.xfs is indeed a noop). * fsck is skipped for filesystems where the relevant helper does not exist, so fs_passno=1 has the same effect for xfs and btrfs filesystems (either way, nothing happens). That still leaves non-systemd systems and calling "fsck -A" manually. Maybe a good solution would be to patch fsck to adopt systemd's behavior, which would avoid every filesystem having to ship these "fake" fsck helpers? What do you think Karel? Cheers, Tom -- 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
