[systemd-devel] [PATCH] fstab-generator: do not check btrfs and xfs

Kai Krakow hurikhan77 at gmail.com
Sun Jun 29 12:51:10 PDT 2014


Lennart Poettering <lennart at poettering.net> schrieb:

> On Sat, 28.06.14 19:49, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl)
> 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.



More information about the systemd-devel mailing list