missing /sbin/fsck.btrfs

missing /sbin/fsck.btrfs

[Chris Murphy]

Hi,

Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful of threads indicating some idea of having it just do a no-op like fsck.xfs does, but then also the idea that /etc/fstab should correctly set fs_passno to 0 instead of such trickery.

I ask due to systemd-fstab-generator seemingly getting the idea from Fedora 20's default /etc/fstab that btrfs should have its file system checked, and during offline  updates, systemd tries to do this, doesn't find /sbin/fsck.btrfs, and then has several dozen fits.

https://bugzilla.redhat.com/show_bug.cgi?id=1034563
https://bugzilla.redhat.com/show_bug.cgi?id=862871

So the question, is there supposed to be (one day) a faux /sbin/fsck.btrfs? Or should things always check /etc/fstab fs_passno and honor the fact there is really no such thing?

Thanks,

Chris Murphy

Re: missing /sbin/fsck.btrfs

[Duncan]

Chris Murphy posted on Mon, 25 Nov 2013 23:40:49 -0700 as excerpted:

> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful of
> threads indicating some idea of having it just do a no-op like fsck.xfs
> does, but then also the idea that /etc/fstab should correctly set
> fs_passno to 0 instead of such trickery.
> 
> I ask due to systemd-fstab-generator seemingly getting the idea from
> Fedora 20's default /etc/fstab that btrfs should have its file system
> checked, and during offline  updates, systemd tries to do this, doesn't
> find /sbin/fsck.btrfs, and then has several dozen fits.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1034563
> https://bugzilla.redhat.com/show_bug.cgi?id=862871
> 
> So the question, is there supposed to be (one day) a faux
> /sbin/fsck.btrfs? Or should things always check /etc/fstab fs_passno and
> honor the fact there is really no such thing?

Just symlink/copy fsck.btrfs to (/bin/)true.

https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs

Or just do the /etc/fstab fs_passno = 0 thing, which is what I did with
reiserfs, so no change in that regard here when I switched to btrfs
for most partitions.

But I'm on gentoo and haven't opted to drink the systemd koolaid yet,
so what it thinks about that I wouldn't know.

-- 
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: missing /sbin/fsck.btrfs

[dima]

On 11/26/2013 04:18 PM, Duncan wrote:
> Chris Murphy posted on Mon, 25 Nov 2013 23:40:49 -0700 as excerpted:
>
>> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful of
>> threads indicating some idea of having it just do a no-op like fsck.xfs
>> does, but then also the idea that /etc/fstab should correctly set
>> fs_passno to 0 instead of such trickery.
>>
>> I ask due to systemd-fstab-generator seemingly getting the idea from
>> Fedora 20's default /etc/fstab that btrfs should have its file system
>> checked, and during offline  updates, systemd tries to do this, doesn't
>> find /sbin/fsck.btrfs, and then has several dozen fits.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1034563
>> https://bugzilla.redhat.com/show_bug.cgi?id=862871
>>
>> So the question, is there supposed to be (one day) a faux
>> /sbin/fsck.btrfs? Or should things always check /etc/fstab fs_passno and
>> honor the fact there is really no such thing?
>
> Just symlink/copy fsck.btrfs to (/bin/)true.
>
> https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs
>
> Or just do the /etc/fstab fs_passno = 0 thing, which is what I did with
> reiserfs, so no change in that regard here when I switched to btrfs
> for most partitions.
>
> But I'm on gentoo and haven't opted to drink the systemd koolaid yet,
> so what it thinks about that I wouldn't know.
>

I think it is better to symlink to true, because otherwise mkinitramfs 
in the default configuration will be complaining about the missing hook 
(can be ignored of course)

Re: missing /sbin/fsck.btrfs

[Chris Murphy]

On Nov 26, 2013, at 12:18 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> 
> 
> Just symlink/copy fsck.btrfs to (/bin/)true.

 I'm not doing this every time I install an OS, most users won't either, and nor will most distributions. So in effect, this suggestion places the burden of implementation on the btrfs-progs package to create it at install time.

> 
> https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs
> 
> Or just do the /etc/fstab fs_passno = 0 thing, which is what I did with
> reiserfs, so no change in that regard here when I switched to btrfs
> for most partitions.

And that's fine, it places the burden on the distribution installer to create a correct /etc/fstab.


Chris Murphy

Re: missing /sbin/fsck.btrfs

[Duncan]

Chris Murphy posted on Tue, 26 Nov 2013 11:43:02 -0700 as excerpted:

> On Nov 26, 2013, at 12:18 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>>> 
>> 
>> Just symlink/copy fsck.btrfs to (/bin/)true.
> 
> I'm not doing this every time I install an OS, most users won't
> either, and nor will most distributions. So in effect, this
> suggestion places the burden of implementation on the btrfs-progs
> package to create it at install time.

I think the "proper" solution is the one below.  This one is just a
workaround, to be done by the sysadmin if the distro or sysadmin
doesn't manage fstab properly.

>> https://btrfs.wiki.kernel.org/index.php/FAQ#What.27s_the_difference_between_btrfsck_and_fsck.btrfs
>> 
>> Or just do the /etc/fstab fs_passno = 0 thing, which is what I did
>> with reiserfs, so no change in that regard here when I switched to
>> btrfs for most partitions.
> 
> And that's fine, it places the burden on the distribution installer
> to create a correct /etc/fstab.

Distro installers should be creating a proper fstab anyway, and sysadmins
should catch it if they change things or if the installer doesn't get it,
because that's ultimately what sysadmins /do/, admin the system, including
setting up an appropriate fstab for their layout, and of course dealing
with distro bugs is a part of adminning a system as well.

And IMO, if an installer, human or automated distro install it doesn't
matter, sets up btrfs, setting anything but a zero/disabled fsck pass
number in fstab is almost certainly a mistake/bug, unless it's deliberately
set elsewise to cover some special case, in which case another step of
the same deliberate process should be symlinking fsck.btrfs to either
true or btrfsck as appropriate.  Because setting anything other that
a pass number of zero for btrfs by default should be exactly that,
a deliberate special-case, ideally documented as such in an fstab
comment and if automated as by an installer script, in that script
as well.

-- 
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: missing /sbin/fsck.btrfs

[Dave Chinner]

On Mon, Nov 25, 2013 at 11:40:49PM -0700, Chris Murphy wrote:
> Hi,
> 
> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful
> of threads indicating some idea of having it just do a no-op like
> fsck.xfs does, but then also the idea that /etc/fstab should
> correctly set fs_passno to 0 instead of such trickery.

You're missing a key thing that fsck.xfs does that fstab expects to
work - it fails with an error if the device is missing. If the
device is present, then fsck.xfs returns success.

We did this because people were having problems when devices took a
long time to instantiate (e.g. SAN, iscsi and other remote devices)
and the 'device exists' check prevents /etc/fstab trying to mount
the filesystems before they are present and then throwing a hissy
fit....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: missing /sbin/fsck.btrfs

[Chris Murphy]

On Nov 26, 2013, at 5:51 PM, Dave Chinner <david@fromorbit.com> wrote:

> On Mon, Nov 25, 2013 at 11:40:49PM -0700, Chris Murphy wrote:
>> Hi,
>> 
>> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful
>> of threads indicating some idea of having it just do a no-op like
>> fsck.xfs does, but then also the idea that /etc/fstab should
>> correctly set fs_passno to 0 instead of such trickery.
> 
> You're missing a key thing that fsck.xfs does that fstab expects to
> work - it fails with an error if the device is missing. If the
> device is present, then fsck.xfs returns success.

The description of fs_passno taken literally doesn't account for this explanation. It just says if fs_passno is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.

So the fstab expects (or is it systemd or an fsck instance spawned by systemd?) this device present/missing flag to occur is a convention? Or by design? Seems goofy.

> We did this because people were having problems when devices took a
> long time to instantiate (e.g. SAN, iscsi and other remote devices)
> and the 'device exists' check prevents /etc/fstab trying to mount
> the filesystems before they are present and then throwing a hissy
> fit….

OK so you're saying you'd want rootfs on XFS to have its fstab entry retain an fs_passno of 1? Or you'd rather see the process responsible for making sure that the claimed rootfs device is made available before throwing hissy fits when it can't be found?


Chris Murphy

Re: missing /sbin/fsck.btrfs

[Chris Murphy]

If I change the bootloader kernel paramter line from ro to rw, and simply wipe out the roofs entry from fstab, I still have a bootable system. Is there a good reason why rootfs on btrfs should initially mount ro? It seems the legacy reason for this is so rootfs is available, yet can still have fsck run on it, after which it's remounted rw. None of that applies to btrfs does it?

In which case we're slightly faster booting rw from the start, which is a bootloader configuration change. And then having installers exclude / from fstab. (Already systemd is mounting rootfs rw anyway, and, using special GPT partitiontypeguids, it's automounting swap and /home even if they're not listed in fstab.)

Any comments on the efficacy of initial ro state when / is on Btrfs?


Chris Murphy

Re: missing /sbin/fsck.btrfs

[Duncan]

Chris Murphy posted on Tue, 26 Nov 2013 21:55:09 -0700 as excerpted:

> If I change the bootloader kernel paramter line from ro to rw, and
> simply wipe out the roofs entry from fstab, I still have a bootable
> system. Is there a good reason why rootfs on btrfs should initially
> mount ro? It seems the legacy reason for this is so rootfs is available,
> yet can still have fsck run on it, after which it's remounted rw. None
> of that applies to btrfs does it?

I did that for awhile with reiserfs.  Pass rw on the kernel commandline 
and skip the whole fsck and remount read-write.

But then I realized it was getting mounted rw, but the other mount 
options weren't getting set, because they weren't passed on the kernel 
commandline (that was before I knew about rootflags= and likely before it 
was documented in kernel-parameters.txt, tho it possibly existed), so I 
went back to ro mounting so I could get noatime, etc, with the remount.

Now of course one could pass rootflags= on the kernel commandline too, 
and make rw just another part of that, particularly since btrfs has a 
whole lot of other mount options one might like to pass 
(autodefrag,compress=lzo,noatime...).  Further, at least for those 
building their own kernel the builtin kernel commandline could be used, 
thus avoiding the hassle of having to actually pass all that stuff in 
from the bootloader.

But meanwhile, I've recently become a ro-rootfs-by-default convert.  I 
now routinely run a read-only root, unless I'm actively updating or 
reconfiguring something and need a read-write root for that.  But it ro 
as booted, remounted rw only for changes, then mounted ro once again.

That's actually a far more stable and safe way to run, particularly since 
I'm running a still not entirely stable btrfs rootfs, since as long as 
it's mounted ro, a system crash is extremely unlikely to cause any damage 
at all.  It's worth noting that traditionally, rootfs was never fully 
unmounted for shutdown anyway, only mounted ro, since it normally 
couldn't be unmounted because executable files were still open for 
reading/execution.  (I understand that systemd, when run from an 
initramfs, can now fully unmount real-root, leaving only the in-memory 
initramfs mounted, but that's not the way things traditionally worked.)

Which is nice, since it means the entire operating system, or at least 
all of it that's on rootfs, is available to help recover other 
filesystems that /were/ mounted read-write at the time of a crash, and 
/did/ have open files...  Having the full system including manpages, a 
browser, etc, available for recovery is a whole lot nicer than trying to 
recover rootfs with the normally extremely limited tools and 
documentation available in the initramfs, for sure!

-- 
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: missing /sbin/fsck.btrfs

[Tom Gundersen]

On Wed, Nov 27, 2013 at 1:51 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Nov 25, 2013 at 11:40:49PM -0700, Chris Murphy wrote:
>> Hi,
>>
>> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a handful
>> of threads indicating some idea of having it just do a no-op like
>> fsck.xfs does, but then also the idea that /etc/fstab should
>> correctly set fs_passno to 0 instead of such trickery.
>
> You're missing a key thing that fsck.xfs does that fstab expects to
> work - it fails with an error if the device is missing. If the
> device is present, then fsck.xfs returns success.
>
> We did this because people were having problems when devices took a
> long time to instantiate (e.g. SAN, iscsi and other remote devices)
> and the 'device exists' check prevents /etc/fstab trying to mount
> the filesystems before they are present and then throwing a hissy
> fit....

Note that this kind of stuff should no longer be necessary, at least
if you use systemd (or I suppose Upstrat, but I didn't check):
Filesystems will only be mounted after their backing devices appear.

Cheers,

Tom

Re: missing /sbin/fsck.btrfs

[Dave Chinner]

On Tue, Nov 26, 2013 at 08:06:36PM -0700, Chris Murphy wrote:
> 
> On Nov 26, 2013, at 5:51 PM, Dave Chinner <david@fromorbit.com>
> wrote:
> 
> > On Mon, Nov 25, 2013 at 11:40:49PM -0700, Chris Murphy wrote:
> >> Hi,
> >> 
> >> Is there supposed to be an /sbin/fsck.btrfs? I'm seeing a
> >> handful of threads indicating some idea of having it just do a
> >> no-op like fsck.xfs does, but then also the idea that
> >> /etc/fstab should correctly set fs_passno to 0 instead of such
> >> trickery.
> > 
> > You're missing a key thing that fsck.xfs does that fstab expects
> > to work - it fails with an error if the device is missing. If
> > the device is present, then fsck.xfs returns success.
> 
> The description of fs_passno taken literally doesn't account for
> this explanation. It just says if fs_passno is not present or
> zero, a value of zero is returned and fsck will assume that the
> filesystem does not need to be checked.

I'm not commenting on what fstab does or does not do - I commented
on the incorrect assertion that was made about fsck.xfs being a
no-op.

> So the fstab expects (or is it systemd or an fsck instance spawned
> by systemd?) this device present/missing flag to occur is a
> convention? Or by design? Seems goofy.

fstab expects that if it is asked for the filesystem to be checked
and the device is missing, then fsck.<foo> will return an error
because the device is missing and it could not be checked....

> > We did this because people were having problems when devices
> > took a long time to instantiate (e.g. SAN, iscsi and other
> > remote devices) and the 'device exists' check prevents
> > /etc/fstab trying to mount the filesystems before they are
> > present and then throwing a hissy fit….
> 
> OK so you're saying you'd want rootfs on XFS to have its fstab
> entry retain an fs_passno of 1?

No, I didn't say that. 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....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: missing /sbin/fsck.btrfs

[Tom Gundersen]

On Mon, Dec 2, 2013 at 12:01 AM, Dave Chinner <david@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

Re: missing /sbin/fsck.btrfs

[Karel Zak]

On Mon, Dec 30, 2013 at 06:18:53PM +0100, Tom Gundersen wrote:
>  * 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?

 It's already implemented for years, "fsck -A" ignores filesystems 
 without fsck.<type> helpers. It only complains if you explicitly
 specify the device on command line (e.g. fsck /dev/sdb1).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com