btrfs check, btrfsck, fsck.btrfs

btrfs check, btrfsck, fsck.btrfs

[Chris Murphy]

Should the initrd/initramfs no longer include btrfsck, and instead include btrfs and fsck.btrfs?

In btrfs-progs 3.14 there is now a 1K /sbin/fsck.btrfs placeholder file.

btrfs and btrfsck files are the same binary, the difference is btrfsck only can do check/repair. Including btrfs instead allows more flexibility to use additional subcommands, and it's also consistent with fsck.btrfs which references btrfs not btrfsck.


Chris Murphy

Re: btrfs check, btrfsck, fsck.btrfs

[Duncan]

Chris Murphy posted on Tue, 20 May 2014 10:56:26 -0600 as excerpted:

> Should the initrd/initramfs no longer include btrfsck, and instead
> include btrfs and fsck.btrfs?

btrfs (the program) should be included in any case as btrfs device scan 
should be run (normally triggered via udev rules when a btrfs filesystem 
block device is detected) to enable mounting multi-device btrfs' (the 
filesystem) from within the initr*.

That's already the case with dracut's btrfs module, anyway, and has been 
for some time.

> In btrfs-progs 3.14 there is now a 1K /sbin/fsck.btrfs placeholder file.

To be more exact, it's a nearly noop shell-script (basically copied from 
fsck.xfs) that simply verifies that the passed in filename exists.  If it 
does, in auto-mode (if called automatically via a passno > 0 in fstab), 
it exits without error.  In non-auto-mode, it simply points the user at 
btrfs check.  If the device doesn't exist, it exits with "8" as the error 
status.  No check other than that the last parameter passed in is 
actually an existing file, not even whether it's actually a device or 
not, is done.

As btrfs (the filesystem) doesn't need a pre-mount check, the 
recommendation is to set passno to 0 for btrfs in any case, in which case 
fsck.btrfs shouldn't be needed at all.

As such, fsck.btrfs really shouldn't be needed in an initr*, since 
whatever's creating the initr* shouldn't be running a pre-mount auto-fsck 
against btrfs in any case, as to do so is certainly a bug.

(Tho with compression the incremental size of a single shell-script just 
over 1 KiB in size before compression should be trivial.)

> btrfs and btrfsck files are the same binary, the difference is btrfsck
> only can do check/repair. Including btrfs instead allows more
> flexibility to use additional subcommands, and it's also consistent with
> fsck.btrfs which references btrfs not btrfsck.

Ideally, btrfsck would be a symlink to btrfs in btrfs-progs, and 
potentially not included in an initr* at all, or if included, likewise 
included as a symlink.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: btrfs check, btrfsck, fsck.btrfs

[Chris Murphy]

On May 20, 2014, at 5:02 PM, Duncan <1i5t5.duncan@cox.net> wrote:

> Chris Murphy posted on Tue, 20 May 2014 10:56:26 -0600 as excerpted:
> 
>> Should the initrd/initramfs no longer include btrfsck, and instead
>> include btrfs and fsck.btrfs?
> 
> btrfs (the program) should be included in any case as btrfs device scan 
> should be run (normally triggered via udev rules when a btrfs filesystem 
> block device is detected) to enable mounting multi-device btrfs' (the 
> filesystem) from within the initr*.
> 
> That's already the case with dracut's btrfs module, anyway, and has been 
> for some time.

Yes you're right. And lsinitrd confirms that both btrfs and btrfsck are in the initramfs.


> 
>> In btrfs-progs 3.14 there is now a 1K /sbin/fsck.btrfs placeholder file.
> 
> To be more exact, it's a nearly noop shell-script (basically copied from 
> fsck.xfs) that simply verifies that the passed in filename exists.  If it 
> does, in auto-mode (if called automatically via a passno > 0 in fstab), 
> it exits without error.  In non-auto-mode, it simply points the user at 
> btrfs check.  If the device doesn't exist, it exits with "8" as the error 
> status.  No check other than that the last parameter passed in is 
> actually an existing file, not even whether it's actually a device or 
> not, is done.
> 
> As btrfs (the filesystem) doesn't need a pre-mount check, the 
> recommendation is to set passno to 0 for btrfs in any case, in which case 
> fsck.btrfs shouldn't be needed at all.
> 
> As such, fsck.btrfs really shouldn't be needed in an initr*, since 
> whatever's creating the initr* shouldn't be running a pre-mount auto-fsck 
> against btrfs in any case, as to do so is certainly a bug.


That ought to be true, but at least on a systemd 212-4 system, it assumes the system root needs to be fsck'd before mounting it. Since the fs isn't mounted, fstab isn't available. And the fstab.empty file I found in the initramfs is in fact empty. So even with fs_passno set to 0, systemd is trying to run fsck.btrfs, which it fails to find, warns about, then moves on.

I filed that bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1098799




> 
> (Tho with compression the incremental size of a single shell-script just 
> over 1 KiB in size before compression should be trivial.)
> 
>> btrfs and btrfsck files are the same binary, the difference is btrfsck
>> only can do check/repair. Including btrfs instead allows more
>> flexibility to use additional subcommands, and it's also consistent with
>> fsck.btrfs which references btrfs not btrfsck.
> 
> Ideally, btrfsck would be a symlink to btrfs in btrfs-progs, and 
> potentially not included in an initr* at all, or if included, likewise 
> included as a symlink.


Yeah it seems to me we should only need btrfs in the initrd/ramfs. It doesn't show up as a link but the Rawhide initramfs, using lsinitrd, lists btrfsck as a 0 byte file.


Chris Murphy

Re: btrfs check, btrfsck, fsck.btrfs

[Duncan]

On Tue, 20 May 2014 18:26:59 -0600
Chris Murphy <lists@colorremedies.com> wrote:

> That ought to be true, but at least on a systemd 212-4 system, it
> assumes the system root needs to be fsck'd before mounting it. Since
> the fs isn't mounted, fstab isn't available. And the fstab.empty file
> I found in the initramfs is in fact empty. So even with fs_passno set
> to 0, systemd is trying to run fsck.btrfs, which it fails to find,
> warns about, then moves on.
> 
> I filed that bug here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1098799

[@ Chris M, I sent this to you only first.  So this one's to the list
only, but it'll have a different message-id, so you'll probably get it
as two different messages, one to the list, one direct to you.]

Hmm... it isn't doing so here.  dracut-037, systemd-212-r4 (the -r4
indicating four gentoo package level revision bumps since the initial
in-tree release of the upstream 037 version).

But I have an install-customized dracut config (tho I no longer use
host-only as explained in my last post, to the degraded boot and
systemd thread), all kernel modules built-in, etc.  If you're running a
generic everything-including-the-kitchen-sink dracut, that might
explain it, since I guess on most filesystems (not reiserfs/xfs/btrfs,
however) it would need to be run.

-- 
Duncan - No HTML messages please, as they are filtered as spam.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: btrfs check, btrfsck, fsck.btrfs

[Chris Murphy]

On May 21, 2014, at 4:47 AM, Duncan <1i5t5.duncan@cox.net> wrote:

> On Tue, 20 May 2014 18:26:59 -0600
> Chris Murphy <lists@colorremedies.com> wrote:
> 
>> That ought to be true, but at least on a systemd 212-4 system, it
>> assumes the system root needs to be fsck'd before mounting it. Since
>> the fs isn't mounted, fstab isn't available. And the fstab.empty file
>> I found in the initramfs is in fact empty. So even with fs_passno set
>> to 0, systemd is trying to run fsck.btrfs, which it fails to find,
>> warns about, then moves on.
>> 
>> I filed that bug here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1098799
> 
> 
> Hmm... it isn't doing so here.  dracut-037, systemd-212-r4 (the -r4
> indicating four gentoo package level revision bumps since the initial
> in-tree release of the upstream 037 version).

systemd 212 and dracut 037 here also.


> But I have an install-customized dracut config (tho I no longer use
> host-only as explained in my last post, to the degraded boot and
> systemd thread), all kernel modules built-in, etc.  If you're running a
> generic everything-including-the-kitchen-sink dracut, that might
> explain it, since I guess on most filesystems (not reiserfs/xfs/btrfs,
> however) it would need to be run.

I've tried both types of initramfs's. The fsck on root is always called, the difference being fsck.btrfs is not in the host-only initramfs, but is in the no-host-only one.

[    1.779007] localhost systemd[1]: Failed to load configuration for systemd-fsck-root.service: No such file or directory
[…snip…]
[    1.780811] localhost systemd[1]: Installed new job initrd-root-fs.target/start as 30
[    1.780818] localhost systemd[1]: Installed new job sysroot.mount/start as 31
[    1.780826] localhost systemd[1]: Installed new job dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.device/start as 32
[    1.780834] localhost systemd[1]: Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 33

The first and last entries are mysteries. There is a /usr/lib/systemd/system/systemd-fsck-root.service so I don't know why it fails to load. The last entry looks like it occurs not by systemd-fsck-root.service but rather /usr/lib/systemd/system/systemd-fsck@.service, which is in the same directory. It reads:

[Unit]
Description=File System Check on %f
Documentation=man:systemd-fsck@.service(8)
DefaultDependencies=no
BindsTo=%i.device
After=systemd-readahead-collect.service systemd-readahead-replay.service %i.device systemd-fsck-root.service
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-fsck %f
StandardOutput=journal+console
TimeoutSec=0

So I'm not sure what's going on.


Chris Murphy