Lennart Poettering <lenn...@poettering.net> schrieb: > On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote: > >> > 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'. > > Is this an upstream thing? Or is that specific to your distro? > > It sounds really wrong to me to do something like what they are > doing. Either they provide a real implementation, or they don't supply > an implementation. Either is fine. But if they supply an implementation > that justs prints a warning will simply mean that various tools > (including systemd) will invoke it, for no reason.
To check this, I've just pulled the original source from git and built it. This is original upstream behavior, no special Gentoo thing. The fsck.btrfs utility is just a shell script. It seems to originate from xfs-progs: https://github.com/josefbacik/btrfs-progs/blob/master/fsck.btrfs They seem to have their own thinking of whether this utility should exist or not according to the introductionary comment. ;-) -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
