Btrfs and integration with GNU ++

Btrfs and integration with GNU ++

[Roy Sigurd Karlsbakk]

Hi all

First of all, thanks for the good work. I first started looking into btrfs some six years back, and things are a lot better now. I just wonder about a few things…

For btrfs to be accepted as a primary filesystem in major distros, I'd think it should integrate with existing tools. Currently, df seems to show good data, while du doesn't. I've been working with ZFS for some time, and there du will show data on disk and du --apparent-size will show how much apparently is on disk according to file sizes. I beleive this only acconuts for compression (not dedup, which I don't use), but still it's neat. Also, lsblk works well with md, showing which md device each device belongs to, while in btrfs land, it only shows the device from /proc/mounts that appear to be mounted. Again, mount should IMHO show btrfs information and not just the some device in the btrfs filesystem.

Lastly - I just did a small test on a 6 drive RAID-6, turned on compression and started cat /proc/zero > testfile - let this run until the filesize was 500GB and stopped it. Made some other test files and a copy of these with --reflink=auto just for kicks. rm test* and waited. While waiting, did a 'echo b > /proc/sysrq-trigger' and fsck started on bootup and took a minute or so to complete. Since the filesystem is rather small (6x8GB VDEVs on top of ZFS with SSD caching, kvm as hypervisor), I wonder how long this fsck job would take if it were on a system with, say, 6 4TB drives. RHEL/CentOS7 just moved to XFS to allow for system crashes without this hour-long fsck job, and I somewhat doubt that btrfs will be the chosen one if it requires the same amount of time as of ext4.

Vennlig hilsen / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.

Re: Btrfs and integration with GNU ++

[Qu Wenruo]

-------- Original Message  --------
Subject: Btrfs and integration with GNU ++
From: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
To: <linux-btrfs@vger.kernel.org>
Date: 2015年05月18日 03:33

> Hi all
>
> First of all, thanks for the good work. I first started looking into btrfs some six years back, and things are a lot better now. I just wonder about a few things…
>
> For btrfs to be accepted as a primary filesystem in major distros, I'd think it should integrate with existing tools. Currently, df seems to show good data, while du doesn't. I've been working with ZFS for some time, and there du will show data on disk and du --apparent-size will show how much apparently is on disk according to file sizes. I beleive this only acconuts for compression (not dedup, which I don't use), but still it's neat. Also, lsblk works well with md, showing which md device each device belongs to, while in btrfs land, it only shows the device from /proc/mounts that appear to be mounted. Again, mount should IMHO show btrfs information and not just the some device in the btrfs filesystem.
>
> Lastly - I just did a small test on a 6 drive RAID-6, turned on compression and started cat /proc/zero > testfile - let this run until the filesize was 500GB and stopped it. Made some other test files and a copy of these with --reflink=auto just for kicks. rm test* and waited. While waiting, did a 'echo b > /proc/sysrq-trigger' and fsck started on bootup and took a minute or so to complete. Since the filesystem is rather small (6x8GB VDEVs on top of ZFS with SSD caching, kvm as hypervisor), I wonder how long this fsck job would take if it were on a system with, say, 6 4TB drives. RHEL/CentOS7 just moved to XFS to allow for system crashes without this hour-long fsck job, and I somewhat doubt that btrfs will be the chosen one if it requires the same amount of time as of ext4.
First, Btrfs, at least in theory, has no need to do fsck.
As the COW design makes it quite safe to sudden power lose.
You can explore your fsck.btrfs and will find that will do nothing, for 
the reason explained above.

Second, Btrfsck is not things like xfs/ext* fsck.
As btrfs is not based on journal, no dirty flag or things like that, 
btrfsck will *always* check all metadata.
So, at least for me, 1 minute is already quite fast for your 6X8TB.
You should compare the time with "fsck.ext* -f".

Thanks,
Qu
>
> Vennlig hilsen / Best regards
>
> roy
> --
> Roy Sigurd Karlsbakk
> (+47) 98013356
> http://blogg.karlsbakk.net/
> GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
> --
> I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk.
> --
> 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: Btrfs and integration with GNU ++

[Duncan]

Roy Sigurd Karlsbakk posted on Sun, 17 May 2015 21:33:27 +0200 as
excerpted:

> Hi all
> 
> First of all, thanks for the good work. I first started looking into
> btrfs some six years back, and things are a lot better now. I just
> wonder about a few things…
> 
> For btrfs to be accepted as a primary filesystem in major distros, I'd
> think it should integrate with existing tools.

Well, fortunately or unfortunately, btrfs is already being accepted as a 
primary fs in major distros.

That despite the fact that it isn't entirely mature yet, and the 
sysadmin's law about backups (if you don't have a backup, by definition 
you value your time and hassle saved in not making it over your data, 
despite any claims to the contrary; if it isn't current, you value the 
time and hassle of keeping current backups more than the loss of the data 
between the time of the backup and now, and a would-be backup isn't a 
backup until it is tested workable/restorable from the tools you'd have 
if the filesystem(s) it's backing up failed) applies double to btrfs 
because it is /not/ fully mature yet.  Yet major distros are making it 
the default without warning people about this, and for people such as 
ordinary desktop users that may not be aware of such cardinal sysadmin's 
rules.

> Currently, df seems to show good data, while du doesn't.

There has been some work put into what df returns to make it so, while 
similar work to du has not yet been released, and in fact only quite 
recently (within the last month) has been proposed on the list.

Maturity of the filesystem, again...

> I've been working with ZFS for some
> time, and there du will show data on disk and du --apparent-size will
> show how much apparently is on disk according to file sizes. I beleive
> this only acconuts for compression (not dedup, which I don't use), but
> still it's neat. Also, lsblk works well with md, showing which md device
> each device belongs to, while in btrfs land, it only shows the device
> from /proc/mounts that appear to be mounted. Again, mount should IMHO
> show btrfs information and not just the some device in the btrfs
> filesystem.
> 
> Lastly - I just did a small test on a 6 drive RAID-6, turned on
> compression and started cat /proc/zero > testfile - let this run until
> the filesize was 500GB and stopped it. Made some other test files and a
> copy of these with --reflink=auto just for kicks. rm test* and waited.
> While waiting, did a 'echo b > /proc/sysrq-trigger' and fsck started on
> bootup and took a minute or so to complete. Since the filesystem is
> rather small (6x8GB VDEVs on top of ZFS with SSD caching, kvm as
> hypervisor), I wonder how long this fsck job would take if it were on a
> system with, say, 6 4TB drives. RHEL/CentOS7 just moved to XFS to allow
> for system crashes without this hour-long fsck job, and I somewhat doubt
> that btrfs will be the chosen one if it requires the same amount of time
> as of ext4.

As Qu mentions, on-mount fsck is not needed on btrfs, as assuming no bugs 
(filesystem maturity, again), due to btrfs' COW nature, commits are 
atomic and the filesystem is self-consistent at every commit.  Commits 
occur every 30 seconds by default (it's a mount option), and there's only 
a very limited journal of fsynced transactions kept since the last 
commit, to be sure they are recoverable even when the filesystem crashes 
between commits, that automatically replays on mount.  So no on-mount fsck 
needed.

In fact, btrfs-tools has shipped with a "null" fsck.btrfs for some time 
now.  It's shell code and thus can be easily examined.  All it does for 
the usual fsck -a is return without error, and if you're not running a 
current version, print a complaint that it doesn't need run at all.  Some 
distro btrfs-tools packages don't even ship it at all.

Even if you have the full btrfs check run at startup, it's normally read-
only and won't fix a thing, unless it's given the --repair option or some 
even stronger fixup option.


So if on-boot fsck took a minute to run on a btrfs, it wasn't because 
anything close to current fsck.btrfs takes that long to run on its own, 
it was either something the distro is doing on its own that's completely 
contrary to recommendations, or it was other things happening in 
parallel, delaying what is after all a simple shell script that does 
nothing but return without error and that should run effectively 
instantly, in human terms anyway.

-- 
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 and integration with GNU ++

[Duncan]

Duncan posted on Mon, 18 May 2015 06:41:09 +0000 as excerpted:

>> Currently, df seems to show good data, while du doesn't.
> 
> There has been some work put into what df returns to make it so, while
> similar work to du has not yet been released, and in fact only quite
> recently (within the last month) has been proposed on the list.

I should have mentioned... what was proposed on-list was actually a btrfs-
specific btrfs filesystem du command, paralleling the existing btrfs 
filesystem df command...

Unlike the system df command, which AFAIK basically simply prints the 
output given to it by the kernel, the system du command does much more of 
its own work, stating the files and doing the math itself.  And in that 
regard, its output is (or should be) accurate.

What the proposed btrfs specific btrfs filesystem du command would do 
differently compared to the system command, as is the case with pretty 
much all informational btrfs subcommands, is print btrfs specific 
information that the system command doesn't.  In that regard, it would 
be... btrfs specific... and thus belongs under the btrfs master command, 
not as part of the normal system command.

Meanwhile, I just looked it up, and posting date was April 23.
Subject: [Patch][RFC] btrfs-progs: add 'du' command
Original poster/author: Mark Fasheh <mfasheh@suse.de>

Link: http://permalink.gmane.org/gmane.comp.file-systems.btrfs/44657

As posted, the patch calculates device (aka disk) usage of the given file 
set using fiemap.  Printed are device usage, unique/unshared size, and 
(for the file set, not individual files) set shared size (the explanation 
for which is a bit complex, see the thread).  Compression information was 
immediately suggested in a reply, but wasn't considered necessary for a 
first implementation.

If you're seriously interested, consider reading the thread and replying 
there if you have additional suggestions/comments.

-- 
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 and integration with GNU ++

[Roy Sigurd Karlsbakk]

>> For btrfs to be accepted as a primary filesystem in major distros, I'd
>> think it should integrate with existing tools.
> 
> Well, fortunately or unfortunately, btrfs is already being accepted as a
> primary fs in major distros.

Interesting - which ones is it that's doing this?

>> Currently, df seems to show good data, while du doesn't.
> 
> There has been some work put into what df returns to make it so, while
> similar work to du has not yet been released, and in fact only quite
> recently (within the last month) has been proposed on the list.
> 
> Maturity of the filesystem, again...

hehe

>> Lastly - I just did a small test on a 6 drive RAID-6, turned on
>> compression and started cat /proc/zero > testfile - let this run until
>> the filesize was 500GB and stopped it. Made some other test files and a
>> copy of these with --reflink=auto just for kicks. rm test* and waited.
>> While waiting, did a 'echo b > /proc/sysrq-trigger' and fsck started on
>> bootup and took a minute or so to complete. Since the filesystem is
>> rather small (6x8GB VDEVs on top of ZFS with SSD caching, kvm as
>> hypervisor), I wonder how long this fsck job would take if it were on a
>> system with, say, 6 4TB drives. RHEL/CentOS7 just moved to XFS to allow
>> for system crashes without this hour-long fsck job, and I somewhat doubt
>> that btrfs will be the chosen one if it requires the same amount of time
>> as of ext4.
> 
> As Qu mentions, on-mount fsck is not needed on btrfs, as assuming no bugs
> (filesystem maturity, again), due to btrfs' COW nature, commits are
> atomic and the filesystem is self-consistent at every commit.  Commits
> occur every 30 seconds by default (it's a mount option), and there's only
> a very limited journal of fsynced transactions kept since the last
> commit, to be sure they are recoverable even when the filesystem crashes
> between commits, that automatically replays on mount.  So no on-mount fsck
> needed.

I didn't run it. Some part of the Jessie startup did, and 1 minute for just 6x8GB (not TB) seems a lot…

roy

Re: Btrfs and integration with GNU ++

[Austin S Hemmelgarn]

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

On 2015-05-18 05:22, Roy Sigurd Karlsbakk wrote:
>>> For btrfs to be accepted as a primary filesystem in major distros, I'd
>>> think it should integrate with existing tools.
>>
>> Well, fortunately or unfortunately, btrfs is already being accepted as a
>> primary fs in major distros.
>
> Interesting - which ones is it that's doing this?
>
While I don't know of any that use it by _default_ yet, I do know that 
it is an easy to use option on most of the big non-comercial distros 
already (Debian, Fedora, Ubuntu, etc.), and a couple (Gentoo, Arch, and 
possibly Slackware) have had the option to use it since it went mainline 
(although that is just a side effect of the installation procedures, not 
any kind of active attempt at support).
>>> Currently, df seems to show good data, while du doesn't.
>>
>> There has been some work put into what df returns to make it so, while
>> similar work to du has not yet been released, and in fact only quite
>> recently (within the last month) has been proposed on the list.
>>
>> Maturity of the filesystem, again...
>
> hehe
>
>>> Lastly - I just did a small test on a 6 drive RAID-6, turned on
>>> compression and started cat /proc/zero > testfile - let this run until
>>> the filesize was 500GB and stopped it. Made some other test files and a
>>> copy of these with --reflink=auto just for kicks. rm test* and waited.
>>> While waiting, did a 'echo b > /proc/sysrq-trigger' and fsck started on
>>> bootup and took a minute or so to complete. Since the filesystem is
>>> rather small (6x8GB VDEVs on top of ZFS with SSD caching, kvm as
>>> hypervisor), I wonder how long this fsck job would take if it were on a
>>> system with, say, 6 4TB drives. RHEL/CentOS7 just moved to XFS to allow
>>> for system crashes without this hour-long fsck job, and I somewhat doubt
>>> that btrfs will be the chosen one if it requires the same amount of time
>>> as of ext4.
>>
>> As Qu mentions, on-mount fsck is not needed on btrfs, as assuming no bugs
>> (filesystem maturity, again), due to btrfs' COW nature, commits are
>> atomic and the filesystem is self-consistent at every commit.  Commits
>> occur every 30 seconds by default (it's a mount option), and there's only
>> a very limited journal of fsynced transactions kept since the last
>> commit, to be sure they are recoverable even when the filesystem crashes
>> between commits, that automatically replays on mount.  So no on-mount fsck
>> needed.
>
> I didn't run it. Some part of the Jessie startup did, and 1 minute for just 6x8GB (not TB) seems a lot…
>
To me, this sounds like some sort of systemd issue, I have heard of it 
having issues occasionally with long delays when handling btrfs 
filesystems with more than 4 devices.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: Btrfs and integration with GNU ++

[Chris Murphy]

On Mon, May 18, 2015 at 5:58 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:

> While I don't know of any that use it by _default_ yet,

Since 5-6 months, openSUSE uses it by default for root fs (including
/boot). /home is on XFS. And snapper is configured to take snapshots
by default as well immediately before and after any system changes
(anything yast is in control of).


-- 
Chris Murphy

Re: Btrfs and integration with GNU ++

[Roy Sigurd Karlsbakk]

>> Interesting - which ones is it that's doing this?
>>
> While I don't know of any that use it by _default_ yet, I do know that
> it is an easy to use option on most of the big non-comercial distros
> already (Debian, Fedora, Ubuntu, etc.), and a couple (Gentoo, Arch, and
> possibly Slackware) have had the option to use it since it went mainline
> (although that is just a side effect of the installation procedures, not
> any kind of active attempt at support).

Seems CentOS 7 also allows for btrfs installs. Wonder if RHEL7 also would do that. Gotta test one day...

>> I didn't run it. Some part of the Jessie startup did, and 1 minute for just
>> 6x8GB (not TB) seems a lot…
>>
> To me, this sounds like some sort of systemd issue, I have heard of it
> having issues occasionally with long delays when handling btrfs
> filesystems with more than 4 devices.

It wasn't just a delay - it was fsck running - it was rather verbose on this.

roy

Re: Btrfs and integration with GNU ++

[Chris Murphy]

On Tue, May 19, 2015 at 11:09 AM, Roy Sigurd Karlsbakk
<roy@karlsbakk.net> wrote:
>>> Interesting - which ones is it that's doing this?
>>>
>> While I don't know of any that use it by _default_ yet, I do know that
>> it is an easy to use option on most of the big non-comercial distros
>> already (Debian, Fedora, Ubuntu, etc.), and a couple (Gentoo, Arch, and
>> possibly Slackware) have had the option to use it since it went mainline
>> (although that is just a side effect of the installation procedures, not
>> any kind of active attempt at support).
>
> Seems CentOS 7 also allows for btrfs installs. Wonder if RHEL7 also would do that. Gotta test one day...

They're meant to be binary compatible in every way, including bugs.
The difference is branding.

>
>>> I didn't run it. Some part of the Jessie startup did, and 1 minute for just
>>> 6x8GB (not TB) seems a lot…
>>>
>> To me, this sounds like some sort of systemd issue, I have heard of it
>> having issues occasionally with long delays when handling btrfs
>> filesystems with more than 4 devices.
>
> It wasn't just a delay - it was fsck running - it was rather verbose on this.

Doubtful because again, the fsck.btrfs is not an fsck, it's a no op.
And on my copy of CentOS 7 it's not running btrfs check let alone
btrfs check --repair. So I don't know what you have going on, but
without a complete journal it's hard to say. I suggest posting the
result of:

'journalctl -b -l -o short monotonic'




-- 
Chris Murphy

Re: Btrfs and integration with GNU ++

[Chris Murphy]

On Tue, May 19, 2015 at 11:09 AM, Roy Sigurd Karlsbakk
<roy@karlsbakk.net> wrote:
>>> Interesting - which ones is it that's doing this?
>>>
>> While I don't know of any that use it by _default_ yet, I do know that
>> it is an easy to use option on most of the big non-comercial distros
>> already (Debian, Fedora, Ubuntu, etc.), and a couple (Gentoo, Arch, and
>> possibly Slackware) have had the option to use it since it went mainline
>> (although that is just a side effect of the installation procedures, not
>> any kind of active attempt at support).
>
> Seems CentOS 7 also allows for btrfs installs. Wonder if RHEL7 also would do that. Gotta test one day...

Also, those CentOS/RHEL 7 kernels are old by Btrfs standards. You
should consider using elrepo kernels (they have kernel 4.0.3 and 4.0.4
right now), and if you can't do that, then I wouldn't use Btrfs, use
XFS instead with those 3.10.x kernels.

-- 
Chris Murphy

Re: Btrfs and integration with GNU ++

[Eric Sandeen]

On 5/19/15 1:09 PM, Chris Murphy wrote:
> On Tue, May 19, 2015 at 11:09 AM, Roy Sigurd Karlsbakk
> <roy@karlsbakk.net> wrote:
>>>> Interesting - which ones is it that's doing this?
>>>>
>>> While I don't know of any that use it by _default_ yet, I do know that
>>> it is an easy to use option on most of the big non-comercial distros
>>> already (Debian, Fedora, Ubuntu, etc.), and a couple (Gentoo, Arch, and
>>> possibly Slackware) have had the option to use it since it went mainline
>>> (although that is just a side effect of the installation procedures, not
>>> any kind of active attempt at support).
>>
>> Seems CentOS 7 also allows for btrfs installs. Wonder if RHEL7 also would do that. Gotta test one day...
> 
> Also, those CentOS/RHEL 7 kernels are old by Btrfs standards. You
> should consider using elrepo kernels (they have kernel 4.0.3 and 4.0.4
> right now), and if you can't do that, then I wouldn't use Btrfs, use
> XFS instead with those 3.10.x kernels.

FWIW, I have been keeping the btrfs codebase in RHEL7 as up to date as possible,
given release frequency constraints.

The kernel is based on 3.10, but the btrfs code is much newer.

-Eric

Re: Btrfs and integration with GNU ++

[Chris Murphy]

On Tue, May 19, 2015 at 1:41 PM, Eric Sandeen <sandeen@redhat.com> wrote:
> On 5/19/15 1:09 PM, Chris Murphy wrote:
>> Also, those CentOS/RHEL 7 kernels are old by Btrfs standards. You
>> should consider using elrepo kernels (they have kernel 4.0.3 and 4.0.4
>> right now), and if you can't do that, then I wouldn't use Btrfs, use
>> XFS instead with those 3.10.x kernels.
>
> FWIW, I have been keeping the btrfs codebase in RHEL7 as up to date as possible,
> given release frequency constraints.
>
> The kernel is based on 3.10, but the btrfs code is much newer.

That's good to know. Thanks for that!

-- 
Chris Murphy

Re: Btrfs and integration with GNU ++

[Duncan]

Chris Murphy posted on Tue, 19 May 2015 14:04:56 -0600 as excerpted:

> On Tue, May 19, 2015 at 1:41 PM, Eric Sandeen <sandeen@redhat.com>
> wrote:
>> On 5/19/15 1:09 PM, Chris Murphy wrote:
>>> Also, those CentOS/RHEL 7 kernels are old by Btrfs standards.
>>> [U]se XFS instead with those 3.10.x kernels.
>>
>> FWIW, I have been keeping the btrfs codebase in RHEL7 as up to date as
>> possible, given release frequency constraints.
>>
>> The kernel is based on 3.10, but the btrfs code is much newer.
> 
> That's good to know. Thanks for that!

Indeed good to know.

I'd say it's common knowledge that RHEL backports major bits of 
functionality from newer kernels such that for RHEL kernels the reported 
version isn't a reliable indicator of the age of the code in question 
against mainstream, but this is the first I've seen confirming 
specifically that btrfs is one such newer-code subsystem, such that for 
RHEL/CentOS users we should be able to quit pressing kernel upgrades so 
hard.

-- 
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 and integration with GNU ++

[Chris Murphy]

On Mon, May 18, 2015 at 3:22 AM, Roy Sigurd Karlsbakk <roy@karlsbakk.net> wrote:

>
> I didn't run it. Some part of the Jessie startup did, and 1 minute for just 6x8GB (not TB) seems a lot…

Systemd issues a generic fsck for root fs, always, even for file
systems that don't have unattended fsck like XFS and btrfs.
Effectively the fs_passno field in fstab is ignored for root fs now.
In order to know what passno is set to required mounting root ro
first, and then executing fsck on an ro filesystem which even ext4
considers dangerous. The fsck.xfs and fsck.btrfs don't really do
anything, if you read their man page you'll see that, but I think they
require all devices present for the fsck to return 0 and systemd to
continue with boot. So I'll bet that for some reason there's a delay
with the devices themselves, or with them all being discovered (by
udev?) and thus the systemd unit for root fs is hanging.

If you're experiencing this 1 minute fsck on a non-root fs btrfs, then
that's a bug. There should be no fsck for btrfs, not even the faux
one. I'd check to make sure fs_passno is set to 0. If not, then I'd
look to the initramfs asking for the unnecessary fsck.


-- 
Chris Murphy

Re: Btrfs and integration with GNU ++

[Russell Coker]

Do you have a reference for fsck on a ro mounted ext4 filesystem being dangerous? The standard behavior of Linux systems has been to fsck a ro mounted ext* root filesystem since long before an initrd was invented.

On May 19, 2015 12:24:39 AM GMT+10:00, Chris Murphy <lists@colorremedies.com> wrote:
>On Mon, May 18, 2015 at 3:22 AM, Roy Sigurd Karlsbakk
><roy@karlsbakk.net> wrote:
>
>>
>> I didn't run it. Some part of the Jessie startup did, and 1 minute
>for just 6x8GB (not TB) seems a lot…
>
>Systemd issues a generic fsck for root fs, always, even for file
>systems that don't have unattended fsck like XFS and btrfs.
>Effectively the fs_passno field in fstab is ignored for root fs now.
>In order to know what passno is set to required mounting root ro
>first, and then executing fsck on an ro filesystem which even ext4
>considers dangerous. The fsck.xfs and fsck.btrfs don't really do
>anything, if you read their man page you'll see that, but I think they
>require all devices present for the fsck to return 0 and systemd to
>continue with boot. So I'll bet that for some reason there's a delay
>with the devices themselves, or with them all being discovered (by
>udev?) and thus the systemd unit for root fs is hanging.
>
>If you're experiencing this 1 minute fsck on a non-root fs btrfs, then
>that's a bug. There should be no fsck for btrfs, not even the faux
>one. I'd check to make sure fs_passno is set to 0. If not, then I'd
>look to the initramfs asking for the unnecessary fsck.

-- 
Sent from my Samsung Galaxy Note 3 with K-9 Mail.

Re: Btrfs and integration with GNU ++

[Austin S Hemmelgarn]

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

On 2015-05-19 03:24, Russell Coker wrote:
> Do you have a reference for fsck on a ro mounted ext4 filesystem being dangerous? The standard behavior of Linux systems has been to fsck a ro mounted ext* root filesystem since long before an initrd was invented.
>
It's only dangerous if fsck changed anything and you then try to use the 
filesystem without umounting it and dropping caches or rebooting.  I 
have had issues in the past with metadata corruption in such cases.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: Btrfs and integration with GNU ++

[Chris Murphy]

On Tue, May 19, 2015 at 1:24 AM, Russell Coker <russell@coker.com.au> wrote:
> Do you have a reference for fsck on a ro mounted ext4 filesystem being dangerous? The standard behavior of Linux systems has been to fsck a ro mounted ext* root filesystem since long before an initrd was invented.

Actually, slight confusion. XFS has a repair dangerously mode
explicitly for repairing ro mounted XFS file systems. The man page for
e2fsck says it's unsafe to fsck a mounted fs. It doesn't explicitly
distinguish between ro and rw mounts, but from this list I've learned
ro mounts aren't guaranteed to be ro, even if they should be ro. The
e2fsck man page says even if it's safe, it's unreliable.

Anyway, it seems worse to me to have a system where you have to ro
mount a file system that you suspect might be inconsistent so that the
fsck binary can be read and then operated on that same file system.
Ancient madness.

-- 
Chris Murphy

Re: Btrfs and integration with GNU ++

[Zygo Blaxell]

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

On Tue, May 19, 2015 at 12:02:31PM -0600, Chris Murphy wrote:
> On Tue, May 19, 2015 at 1:24 AM, Russell Coker <russell@coker.com.au> wrote:
> > Do you have a reference for fsck on a ro mounted ext4 filesystem being dangerous? The standard behavior of Linux systems has been to fsck a ro mounted ext* root filesystem since long before an initrd was invented.
> 
> Actually, slight confusion. XFS has a repair dangerously mode
> explicitly for repairing ro mounted XFS file systems. The man page for
> e2fsck says it's unsafe to fsck a mounted fs. It doesn't explicitly
> distinguish between ro and rw mounts, but from this list I've learned
> ro mounts aren't guaranteed to be ro, even if they should be ro. The
> e2fsck man page says even if it's safe, it's unreliable.
> 
> Anyway, it seems worse to me to have a system where you have to ro
> mount a file system that you suspect might be inconsistent so that the
> fsck binary can be read and then operated on that same file system.
> Ancient madness.

The ancient method was to run fsck on a RO mounted root filesystem,
and if fsck corrected errors, immediately reboot to avoid corruption.
Hopefully the second boot gets past the root filesystem, which is
theoretically now clean.  This fails badly if the fsck needs to touch
metadata required for the fsck or reboot, leading to failure of the
init scripts (there is no systemd in the ancient method) followed by
potentially massive root filesystem corruption.  That sounds bad, but in
practical terms there were so many failure modes in the ancient method
that there's no point in choosing just one to get upset over.  ;)

These days we have initramfs, which can treat the root filesystem like
any other filesystem, and check it fully offline before mounting it.
Put dropbear on the initramfs and the filesystem can be interactively
repaired over the network before mounting it too.

Alas, I don't know of any distros that handle root mounts correctly.
I always have to roll my own initramfs to get it right.  >:-/

> 
> -- 
> Chris Murphy
> --
> 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

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

Re: Btrfs and integration with GNU ++

[David Sterba]

On Mon, May 18, 2015 at 11:22:08AM +0200, Roy Sigurd Karlsbakk wrote:
> >> For btrfs to be accepted as a primary filesystem in major distros, I'd
> >> think it should integrate with existing tools.
> > 
> > Well, fortunately or unfortunately, btrfs is already being accepted as a
> > primary fs in major distros.
> 
> Interesting - which ones is it that's doing this?

openSUSE 13.2 started with btrfs as default for the root filesystem,
while it has been an installation option in previous versions.

SLES 12 goes for btrfs as default for the root filesystem and xfs for
the data partitions.

[...]
> > Maturity of the filesystem, again...
> 
> hehe

That's the most frequently raised point. The enterprise kernel gets
more attention regarding backporting the fixes to an old codebase, you
can find fixes from very recent upstream versions.

The kernel development is open for current and upcoming products, you
can see the tree broken out to separate patches at http://kernel.suse.com .

The upstream kernel has a different release cycle and adds features
together with bugfixes, sometimes not all the fixes make it to the
major release. Then it's usually fixed via the stable releases.

The enterprise kernel can afford to skip most of the features and
backport only relevant fixes. Stability of such kernel is different from
the upstream one, not only because of btrfs but also because of tons of
new code in other subsystems.

Re: Btrfs and integration with GNU ++

[Eric Sandeen]

On 5/17/15 2:33 PM, Roy Sigurd Karlsbakk wrote:
> Hi all

> Lastly - I just did a small test on a 6 drive RAID-6, turned on
> compression and started cat /proc/zero > testfile - let this run
> until the filesize was 500GB and stopped it. Made some other test
> files and a copy of these with --reflink=auto just for kicks. rm
> test* and waited. While waiting, did a 'echo b > /proc/sysrq-trigger'
> and fsck started on bootup and took a minute or so to complete. Since
> the filesystem is rather small (6x8GB VDEVs on top of ZFS with SSD
> caching, kvm as hypervisor), I wonder how long this fsck job would
> take if it were on a system with, say, 6 4TB drives. RHEL/CentOS7
> just moved to XFS to allow for system crashes without this hour-long
> fsck job, and I somewhat doubt that btrfs will be the chosen one if
> it requires the same amount of time as of ext4.

Others have mentioned this as well, but I'll say it more broadly:

echo b > /proc/sysrq-trigger should not require a fsck on any journaling
filesystem - xfs, ext3, ext4, or btrfs - that's the whole reason you pay
the slight overhead for metadata journaling at runtime, right?

Was it really running a fsck?

-Eric