Lennart Poettering <[email protected]> schrieb: > On Sat, 28.06.14 19:49, Zbigniew Jędrzejewski-Szmek ([email protected]) > wrote: > >> fsck.btrfs and fsck.xfs are documented to return immediately, so there is >> little sense in running them. Avoids some user confusion and a few lines >> in the logs. >> >> +static bool mount_skip_fsck(const char *fstype) { >> + static const char table[] = >> + "btrfs\0" >> + "xfs\0"; >> + >> + return fstype && nulstr_contains(table, fstype); >> +} > > This sounds really unnecessary, no? We already have fsck_exists() in > place that since a very recent commit of mine even detects a per-fstype > fsck implementation being linked to /bin/true... I also downgraded all > warnings for cases like that to LOG_DEBUG, hence the xfs/btrfs case > should already be covered nicely, and fully generic... Why do we need > another explicit blacklist on top of that?
My version of fsck.btrfs is not symlinked to /bin/true, it's an ordinary binary generating the following output: # /sbin/fsck.btrfs /dev/sdb3 If you wish to check the consistency of a BTRFS filesystem or repair a damaged filesystem, see btrfs(8) subcommand 'check'. From the man page: | Traditional filesystems need to run their respective fsck utility in case | the filesystem was not unmounted cleanly and the log needs to be replayed | before mount. This is not needed for BTRFS. You should set fs_passno to 0. | | If you wish to check the consistency of a BTRFS filesystem or repair a | damaged filesystem, see btrfs-check(8). By default the filesystem | consistency is checked, the repair mode is enabled via --repair option | (use with care!). | | The options are all the same and detect if fsck.btrfs is executed in non- | interactive mode and exits with success, otherwise prints a message about | btrfs check. Thus, in non-interactive mode it simply returns true. But I'm in common with you that blacklisting seems wrong. One time, fsck.btrfs might really do something useful, e.g. triggering offline repair of filesystem parts that have been detected damaged during online use and cannot be repaired online. -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
