fsck.btrfs

fsck.btrfs

[Gene Czarcinski]

I am new to btrfs and have begun exploring and testing it.  One of these 
tests is to install Fedora 18 into a btrfs volume only leaving /boot and 
swap on regular partitions.  BTW, this is on qemu/kvm/libvirt virtuals.

I discovered an error was occurring during bootup because systemd was 
attempting to start fsck.btrfs and it was missing.

1. Would btrfsck be the appropriate program to run at bootup?  If it is, 
with what parameters?

2.  Should there be a fsck.btrfs but it has not been written yet?

3. Does btrfs even need a "fsck.btrfs"?

I get the distinct impression that "btrfs is not your father's 
filesystem" and thus need to be looked at very differently.

Gene

Re: fsck.btrfs

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

On Sat, Dec 22, 2012 at 08:44:13AM -0500, Gene Czarcinski wrote:
> I am new to btrfs and have begun exploring and testing it.  One of
> these tests is to install Fedora 18 into a btrfs volume only leaving
> /boot and swap on regular partitions.  BTW, this is on
> qemu/kvm/libvirt virtuals.
> 
> I discovered an error was occurring during bootup because systemd
> was attempting to start fsck.btrfs and it was missing.
> 
> 1. Would btrfsck be the appropriate program to run at bootup?  If it
> is, with what parameters?

   No, it's not necessary to run an fs checker on every boot. You can
either turn off the checks in fstab, or symlink /sbin/fsck.btrfs to
/bin/true.

> 2.  Should there be a fsck.btrfs but it has not been written yet?
> 
> 3. Does btrfs even need a "fsck.btrfs"?

   There is a need for checking/fixing tools, but not as much as with
many other filesystems. For example, btrfs will verify checksums on
read, and everything is checksummed (including metadata); blocks
failing the checksum can be corrected if there is another copy
available (e.g. RAID-1 or DUP, in the case of default metadata). Other
forms of minor corruption (missing backrefs, etc) are dealt with by
the kernel as it finds them.

   Some more serious forms of corruption are also dealt with by the
kernel -- for example, looking for earlier tree roots with the -o
recovery mount option, which should always be your first port of call
with an unmountable filesystem.

   That said, there's things that the kernel code can't cope with
(extent tree corruption, loss of the chunk tree), and those should be
done off-line by btrfsck. We don't have chunk tree rebuild capability
yet, but it was something that Chris was working on a while ago.

   So btrfsck should not be used unless you know that there's
something fundamentally wrong and that btrfsck can fix it. It's not a
generic "catch-all" thing like many other FS's fsck tools. With btrfs,
if it mounts, it's probably OK.

> I get the distinct impression that "btrfs is not your father's
> filesystem" and thus need to be looked at very differently.

   Indeed. :)

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- But people have always eaten people,  / what else is there to ---  
         eat?  / If the Juju had meant us not to eat people / he         
                     wouldn't have made us of meat.                      

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: fsck.btrfs

[Zach Brown]

> > 1. Would btrfsck be the appropriate program to run at bootup?  If it
> > is, with what parameters?
> 
>    No, it's not necessary to run an fs checker on every boot. You can
> either turn off the checks in fstab, or symlink /sbin/fsck.btrfs to
> /bin/true.

For what it's worth, I gather that the XFS guys used to do the latter
and that it broke something.  Somewhere.  I have no idea what.

Hence fsck.xfs(8) which has perhaps the greatest description in its man
page. 

- z

Re: fsck.btrfs

[Eric Sandeen]

On Jan 3, 2013, at 1:08 PM, Zach Brown <zab@zabbo.net> wrote:

>>> 1. Would btrfsck be the appropriate program to run at bootup?  If it
>>> is, with what parameters?
>> 
>>   No, it's not necessary to run an fs checker on every boot. You can
>> either turn off the checks in fstab, or symlink /sbin/fsck.btrfs to
>> /bin/true.
> 
> For what it's worth, I gather that the XFS guys used to do the latter
> and that it broke something.  Somewhere.  I have no idea what.
> 

Yeah, lost in the mists of time by now.

Seems like maybe by now system installers should set up fstab correctly for a journaling ds, but since ext[34] wants boot-time fsck despite journaling, maybe it's best to provide a fsck.$FS even if it's a no-op.

> Hence fsck.xfs(8) which has perhaps the greatest description in its man
> page. 
> 
\o/ 

-Eric

> - z
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: fsck.btrfs

[David Sterba]

On Sat, Dec 22, 2012 at 02:27:33PM +0000, Hugo Mills wrote:
> On Sat, Dec 22, 2012 at 08:44:13AM -0500, Gene Czarcinski wrote:
> > I am new to btrfs and have begun exploring and testing it.  One of
> > these tests is to install Fedora 18 into a btrfs volume only leaving
> > /boot and swap on regular partitions.  BTW, this is on
> > qemu/kvm/libvirt virtuals.
> > 
> > I discovered an error was occurring during bootup because systemd
> > was attempting to start fsck.btrfs and it was missing.
> > 
> > 1. Would btrfsck be the appropriate program to run at bootup?  If it
> > is, with what parameters?
> 
>    No, it's not necessary to run an fs checker on every boot. You can
> either turn off the checks in fstab, or symlink /sbin/fsck.btrfs to
> /bin/true.

Wiki updated to describe the difference and best practices.

david

Re: fsck.btrfs

[Chris Murphy]

On Dec 22, 2012, at 6:44 AM, Gene Czarcinski <gene@czarc.net> wrote:

> I am new to btrfs and have begun exploring and testing it.  One of these tests is to install Fedora 18 into a btrfs volume only leaving /boot and swap on regular partitions.  BTW, this is on qemu/kvm/libvirt virtuals.
> 
> I discovered an error was occurring during bootup because systemd was attempting to start fsck.btrfs and it was missing.
> 
> 1. Would btrfsck be the appropriate program to run at bootup?  If it is, with what parameters?

I'd check /etc/fstab. I'm pretty sure at the moment most distros including Fedora are defaulting to fstab options 1 1 for btrfs which causes the described behavior. I have filed a Fedora bug against the installer which is responsible for creating fstab.

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



Chris Murphy