shall distros run btrfsck on boot?

shall distros run btrfsck on boot?

[Christoph Anton Mitterer]

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

Hey.

Short question since that came up on debian-devel.

Now that btrfs check get's more and more useful, are the developers
going to recommend running it periodically on boot (of course that
wouldn't work right now, as it would *always* check)?

Plus... is btrfs check (without any arguments) non-desctructive, or are
there corner-cases where it may lead to any changes on the devices?

Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: shall distros run btrfsck on boot?

[Wang Shilong]

On Tue, Nov 24, 2015 at 12:02 PM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> Hey.
>
> Short question since that came up on debian-devel.
>
> Now that btrfs check get's more and more useful, are the developers
> going to recommend running it periodically on boot (of course that
> wouldn't work right now, as it would *always* check)?
>
> Plus... is btrfs check (without any arguments) non-desctructive, or are
> there corner-cases where it may lead to any changes on the devices?

As far as i know, 'btrfs check' did not repair anything in default.
only output errors if repair options not specified.

Regards,
Shilong
>
> Thanks,
> Chris.

Re: shall distros run btrfsck on boot?

[Duncan]

Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:02:34 +0100 as
excerpted:

> Hey.
> 
> Short question since that came up on debian-devel.
> 
> Now that btrfs check get's more and more useful, are the developers
> going to recommend running it periodically on boot (of course that
> wouldn't work right now, as it would *always* check)?

I'm a list regular and btrfs user, not a dev, but all the indications 
continue to point to _not_ running it automatically at boot, nobody even 
_suggesting_ otherwise.  The btrfs kernel code itself detects and often 
corrects many problems, and btrfs check is simply not recommended for 
automatic at-boot scheduling -- if the kernel code can't fix it without 
intervention, then the problem is too serious to be fixed without 
intervention by some scheduled btrfs check run, as well.

In fact, take a look at the shipped fsck.btrfs shell-script, based upon 
the xfs one.  As both the code and the comments suggest, it's 
specifically designed to simply return success (well, if the given device 
exists, if not it does error out on that), without actually checking 
anything (beyond simple device existence).  If it's run in auto mode, as 
it would be with an on-boot run, it does nothing else.  If it's not run 
in auto mode, suggesting that a misinformed user attempted to run it, it 
prints a message redirecting them to btrfs check.

That's pretty clear as to intent -- btrfs check is simply not designed or 
intended to ever be run at boot.

> Plus... is btrfs check (without any arguments) non-desctructive, or are
> there corner-cases where it may lead to any changes on the devices?

Btrfs check, without arguments, is designed to be read-only.  AFAIK, the 
only way it wouldn't be would be if there was a serious bug.

-- 
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: shall distros run btrfsck on boot?

[Eric Sandeen]

On 11/23/15 10:35 PM, Duncan wrote:
> Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:02:34 +0100 as
> excerpted:
> 
>> Hey.
>>
>> Short question since that came up on debian-devel.
>>
>> Now that btrfs check get's more and more useful, are the developers
>> going to recommend running it periodically on boot (of course that
>> wouldn't work right now, as it would *always* check)?
> 
> I'm a list regular and btrfs user, not a dev, but all the indications 
> continue to point to _not_ running it automatically at boot, nobody even 
> _suggesting_ otherwise.  The btrfs kernel code itself detects and often 
> corrects many problems, and btrfs check is simply not recommended for 
> automatic at-boot scheduling -- if the kernel code can't fix it without 
> intervention, then the problem is too serious to be fixed without 
> intervention by some scheduled btrfs check run, as well.
> 
> In fact, take a look at the shipped fsck.btrfs shell-script, based upon 
> the xfs one.

FWIW, fsck.xfs is a no-op because xfs is a *journaling filesystem* and an
unclean shutdown is not a reason to force a filesystem repair on the next
boot.

...that's what the journal was for...!  The filesystem should be 100%
consistent after a mount & a log replay.

The only reason fsck.xfs came into existence was to satisfy initscripts,
IIRC.

-Eric

Re: shall distros run btrfsck on boot?

[Christoph Anton Mitterer]

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

On Tue, 2015-11-24 at 04:35 +0000, Duncan wrote:
> I'm a list regular and btrfs user, not a dev, but all the indications
 
> continue to point to _not_ running it automatically at boot, nobody
> even 
> _suggesting_ otherwise.
Sure, I just asked because maybe that would have just been an
anachronism from the days btrfsck was much more alpha.


>   The btrfs kernel code itself detects and often 
> corrects many problems, and btrfs check is simply not recommended for
> automatic at-boot scheduling -- if the kernel code can't fix it
> without 
> intervention, then the problem is too serious to be fixed without 
> intervention by some scheduled btrfs check run, as well.
I once had an issue with a btrfs, where the kernel didn't show anything
but btrfsck did...(not the one Qu's currently looking into).
And I though the same is basically the case for other filesystems like
ext.


> In fact, take a look at the shipped fsck.btrfs shell-script, based
> upon 
> the xfs one.  As both the code and the comments suggest, it's 
> specifically designed to simply return success
Sure, but that could have simply been forgotten to update...


Thanks for the update on the status in that matter :)
Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: shall distros run btrfsck on boot?

[Qu Wenruo]

Christoph Anton Mitterer wrote on 2015/11/24 05:43 +0100:
> On Tue, 2015-11-24 at 04:35 +0000, Duncan wrote:
>> I'm a list regular and btrfs user, not a dev, but all the indications
>
>> continue to point to _not_ running it automatically at boot, nobody
>> even
>> _suggesting_ otherwise.
> Sure, I just asked because maybe that would have just been an
> anachronism from the days btrfsck was much more alpha.
>
>
>>    The btrfs kernel code itself detects and often
>> corrects many problems, and btrfs check is simply not recommended for
>> automatic at-boot scheduling -- if the kernel code can't fix it
>> without
>> intervention, then the problem is too serious to be fixed without
>> intervention by some scheduled btrfs check run, as well.
> I once had an issue with a btrfs, where the kernel didn't show anything
> but btrfsck did...(not the one Qu's currently looking into).
> And I though the same is basically the case for other filesystems like
> ext.
>
>
>> In fact, take a look at the shipped fsck.btrfs shell-script, based
>> upon
>> the xfs one.  As both the code and the comments suggest, it's
>> specifically designed to simply return success
> Sure, but that could have simply been forgotten to update...
>
>
> Thanks for the update on the status in that matter :)
> Cheers,
> Chris.
>

Another point of never running btrfsck at boot time is, it's super 
SLOOOOOOOOOOOOOOOOOOOW!
And you should have experienced it during the false alert investigation. :)

It's SLOOOOOOOOOOOOOOOOOOW because it will need to iterate all the 
metadata of filesystems to make sure every thing devs can think about is OK.

Unlike traditional filesystem (maybe only ext*), it has some dirty flag 
in superblock or things like that to indicate a filesystem needs extra 
check, and e2fsck will only do comprehensive check if the filesystem is 
dirty.
That's why e2fsck can be run at boot time, as most of time, it just 
finds the fs is clean and no extra check.

But btrfs doesn't use the old-fashion method, it uses COW to protect 
metadata. So btrfsck is only designed to do comprehensive check and it's 
very SLOOOOOOOOOOOOW (not to mention sometimes it's buggy and too 
sensitive to give false alert).

Thanks,
Qu

-- 
This message has been scanned for viruses and
dangerous content by FCNIC, and is
believed to be clean.

Re: shall distros run btrfsck on boot?

[Duncan]

Christoph Anton Mitterer posted on Tue, 24 Nov 2015 05:43:31 +0100 as
excerpted:

[Duncan wrote...]
>> The btrfs kernel code itself detects and often
>> corrects many problems, and btrfs check is simply not recommended for
>> automatic at-boot scheduling -- if the kernel code can't fix it without
>> intervention, then the problem is too serious to be fixed without
>> intervention by some scheduled btrfs check run, as well.

> I once had an issue with a btrfs, where the kernel didn't show anything
> but btrfsck did...(not the one Qu's currently looking into).


That wouldn't be entirely uncommon, because as Eric mentions, btrfs check 
is intended to be thorough, where the kernel mount-time check is intended 
to be fast.

But of course, as Eric also mentions, that's yet another reason you don't 
want btrfs check running at boot... it's *SSLLLOOWWWWW*, because it's 
being thorough.

There are times you'd want to run btrfs check, the reason it's even there 
as a subcommand, but that would be when the filesystem either fails to 
mount, or when it exhibits other serious symptoms of problems... send and 
balance fails, remount-readonlys, nasty messages in the kernel log, etc.  

Careful admins may want to run btrfs check periodically in any case, but 
because it /is/ slow, and because it /isn't/ supposed to be needed for 
routine issues, they probably don't want to be doing it at boot when 
everything else is waiting on it.

Because you don't want your boot taking hours...  And in many cases, if a 
check /is/ going to take hours and even then not guarantee that the 
filesystem is workable, admins may want to simply blow away the 
filesystem, recreate it, and copy everything back to it from backups, 
rather than spending that much time on something that still has a good 
chance of being broken afterward.

-- 
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: shall distros run btrfsck on boot?

[Duncan]

Duncan posted on Tue, 24 Nov 2015 06:46:18 +0000 as excerpted:

> That wouldn't be entirely uncommon, because as Eric mentions, btrfs
> check is intended to be thorough, where the kernel mount-time check is
> intended to be fast.
> 
> But of course, as Eric also mentions, that's yet another reason you
> don't want btrfs check running at boot... it's *SSLLLOOWWWWW*, because
> it's being thorough.

Oops!  Mis-attribution.  Qu not Eric.

(I had read both replies in my email but only saw Eric's on the list, 
which I read in my news client via gmane's list2news service, when I 
composed the above.  So I presumed the points I remembered being made 
were from Eric's post, when it was Qu's.) 

-- 
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: shall distros run btrfsck on boot?

[Eric Sandeen]

On 11/24/15 12:56 AM, Duncan wrote:
> Duncan posted on Tue, 24 Nov 2015 06:46:18 +0000 as excerpted:
> 
>> That wouldn't be entirely uncommon, because as Eric mentions, btrfs
>> check is intended to be thorough, where the kernel mount-time check is
>> intended to be fast.
>>
>> But of course, as Eric also mentions, that's yet another reason you
>> don't want btrfs check running at boot... it's *SSLLLOOWWWWW*, because
>> it's being thorough.
> 
> Oops!  Mis-attribution.  Qu not Eric.
> 
> (I had read both replies in my email but only saw Eric's on the list, 
> which I read in my news client via gmane's list2news service, when I 
> composed the above.  So I presumed the points I remembered being made 
> were from Eric's post, when it was Qu's.) 

Yeah, I don't think that being thorough requires being slow.  ;)

In a nutshell, though, I think a filesystem repair should be an admin-initiated
action, not something that surprises you on a boot, at least for a journaling
filesystem which is designed to maintain its integrity even in the face of
a power loss or crash.

-Eric

Re: shall distros run btrfsck on boot?

[Christoph Anton Mitterer]

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

On Tue, 2015-11-24 at 11:14 -0600, Eric Sandeen wrote:
> In a nutshell, though, I think a filesystem repair should be an
> admin-initiated
> action, not something that surprises you on a boot, at least for a
> journaling
> filesystem which is designed to maintain its integrity even in the
> face of
> a power loss or crash.

Well I wouldn't agree here... I maintain some >2PiB of storage for a
LHC Tier-2,... right now everything with ext4.
During normal operation we can of course not have any fsck, but every
now and then, when we reboot, it happens automatically,... and
regularly shows at least some (apparently non-serious) glitches.


IMHO, either the kernel driver itself already checks "everything", then
we wouldn't need a dedicated check tool.
Or it does not, but in that case, there will be people who want to have
that in-depth checks run regularly (and even if it's just every half a
year).
I better wait half an hour at boot, and find such errors, rather than
that they silently pile up until I really run into troubles.

That being said, of course it should be configurable for the admin...
and it is, via fstab.
So apart from that, given the expectation that btrfsck should be rock-
solid as e.g. e2fsck in some future, I wouldn't see why people
shouldn't have the necessary facilities to have it auto-run.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: shall distros run btrfsck on boot?

[Austin S Hemmelgarn]

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

On 2015-11-24 12:23, Christoph Anton Mitterer wrote:
> On Tue, 2015-11-24 at 11:14 -0600, Eric Sandeen wrote:
>> In a nutshell, though, I think a filesystem repair should be an
>> admin-initiated
>> action, not something that surprises you on a boot, at least for a
>> journaling
>> filesystem which is designed to maintain its integrity even in the
>> face of
>> a power loss or crash.
>
> Well I wouldn't agree here... I maintain some >2PiB of storage for a
> LHC Tier-2,... right now everything with ext4.
> During normal operation we can of course not have any fsck, but every
> now and then, when we reboot, it happens automatically,... and
> regularly shows at least some (apparently non-serious) glitches.
Yeah, that's pretty normal for any large storage array with a high 
uptime.  ext4 also doesn't correct anything on the fly, so it's more 
important that you always run a check on boot when you don't reboot 
often (which brings up why i personally suggest stuff like GlusterFS or 
Ceph for large scale data storage, you can reboot individual nodes one 
at a time, have zero down time, and maintain a high degree of 
performance and data safety).
>
> IMHO, either the kernel driver itself already checks "everything", then
> we wouldn't need a dedicated check tool.
> Or it does not, but in that case, there will be people who want to have
> that in-depth checks run regularly (and even if it's just every half a
> year).
> I better wait half an hour at boot, and find such errors, rather than
> that they silently pile up until I really run into troubles.
Well, that depends on the type of errors.  XFS doesn't need a fsck on 
mount usually, but there is still a xfs_repair tool for fixing badly 
damaged filesystems that the kernel can't mount.  btrfs check falls into 
the same general usage as XFS repair, IOW, if the system was shut down 
cleanly, you're fine barring software bugs, but if it crashed, you 
should be running a check on the FS.  Like I mentioned above, ext4 
doesn't correct errors while online, it either (depending on how the fs 
is configured) ignores them, goes read-only, or panics the system. 
BTRFS on the other hand, can correct many types of errors while online 
(that's part of what scrub is for), and is usually pretty resilient when 
it comes to disk errors (I have a few TB worth of data on assorted BTRFS 
filesystems, I run scrubs on them weekly (which usually turns up about a 
single block error across the whole data set per month), and run a check 
on them monthly, which has never turned up anything unless the system 
had crashed).
>
> That being said, of course it should be configurable for the admin...
> and it is, via fstab.
> So apart from that, given the expectation that btrfsck should be rock-
> solid as e.g. e2fsck in some future, I wouldn't see why people
> shouldn't have the necessary facilities to have it auto-run.
btrfsck has to parse all the data in the FS, and unlike ext4, BTRFS has 
multiple copies of each metadata block (and often on large filesystems, 
is configured for multiple copies of each data block), and has checksums 
on _everything_, which need to be validated.  There is no way that this 
can be made all that much faster short of getting faster hardware to run 
it on.


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

Re: shall distros run btrfsck on boot?

[Eric Sandeen]

On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:

> if the system was
> shut down cleanly, you're fine barring software bugs, but if it
> crashed, you should be running a check on the FS.

Um, no...

The *entire point* of having a journaling filesystem is that after a
crash or power loss, a journal replay on next mount will bring the
metadata into a consistent state.

-Eric

Re: shall distros run btrfsck on boot?

[Hugo Mills]

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

On Tue, Nov 24, 2015 at 04:26:47PM -0600, Eric Sandeen wrote:
> On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:
> 
> > if the system was
> > shut down cleanly, you're fine barring software bugs, but if it
> > crashed, you should be running a check on the FS.
> 
> Um, no...
> 
> The *entire point* of having a journaling filesystem is that after a
> crash or power loss, a journal replay on next mount will bring the
> metadata into a consistent state.

   Not an actual argument within the discussion, but an interesting
observation on a fine distinction:

   It's interesting to note that there's a difference here between
journalling and CoW filesystems. A journalling FS needs a journal
replay to become consistent. A CoW FS is _always_ consistent, by
design. Now, btrfs has a log that should be replayed after an unclean
shutdown, but that's all about the data that got written within the
current transaction that wasn't committed, rather than about FS
metadata consistency. This means that a read-only mount of btrfs can
_actually_ be read-only, not modifying any of the data on the disk,
whereas a read-only mount of a journalling FS _must_ modify the disk
data after an unclean shitdown, in order to be useful (because the FS
isn't consistent without the journal replay).

   Hugo.

-- 
Hugo Mills             | I'll take your bet, but make it ten thousand francs.
hugo@... carfax.org.uk | I'm only a _poor_ corrupt official.
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                              Capt. Renaud, Casablanca

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

Re: shall distros run btrfsck on boot?

[Christoph Anton Mitterer]

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

On Tue, 2015-11-24 at 22:33 +0000, Hugo Mills wrote:
> whereas a read-only mount of a journalling FS _must_ modify the disk
> data after an unclean shitdown, in order to be useful (because the FS
> isn't consistent without the journal replay).
I've always considered that rather a bug,... or at least a very
annoying handling in ext*
If I specify "read-only" than nothing should ever be written.
If that's not possible because of an unclean shutdown and a journal
that needs to be replayed, the mount should (without any further
special option) rather fail then mount it pseudo-read-only.

Cheers,
Chris

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]

Re: shall distros run btrfsck on boot?

[Hugo Mills]

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

On Wed, Nov 25, 2015 at 12:01:49AM +0100, Christoph Anton Mitterer wrote:
> On Tue, 2015-11-24 at 22:33 +0000, Hugo Mills wrote:
> > whereas a read-only mount of a journalling FS _must_ modify the disk
> > data after an unclean shitdown, in order to be useful (because the FS
> > isn't consistent without the journal replay).
> I've always considered that rather a bug,... or at least a very
> annoying handling in ext*
> If I specify "read-only" than nothing should ever be written.
> If that's not possible because of an unclean shutdown and a journal
> that needs to be replayed, the mount should (without any further
> special option) rather fail then mount it pseudo-read-only.

   At one point, I _think_, btrfs did replay the log tree
unconditionally, even on a RO mount, but it doesn't any more. There
was certainly some discussion on the point. It's actually quite handy
sometimes -- if you have a corrupt log tree, you can check it by
mounting RO (when it works) and RW (when it fails because the log tree
is broken), and the do btrfs-zero-log to clear it.

   For the record, this is about the only good use for btrfs-zero-log.
It doesn't magically fix anything else. (Yes, this is another futile
attempt at killing the persistent "btrfs-zero-log fixes everything"
meme that's been doing the rounds for the last few years).

   Hugo.

-- 
Hugo Mills             | Never underestimate the bandwidth of a Volvo filled
hugo@... carfax.org.uk | with backup tapes.
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

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

Re: shall distros run btrfsck on boot?(Off topic, btrfs per-inode tree idea)

[Qu Wenruo]

Hugo Mills wrote on 2015/11/24 22:33 +0000:
> On Tue, Nov 24, 2015 at 04:26:47PM -0600, Eric Sandeen wrote:
>> On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:
>>
>>> if the system was
>>> shut down cleanly, you're fine barring software bugs, but if it
>>> crashed, you should be running a check on the FS.
>>
>> Um, no...
>>
>> The *entire point* of having a journaling filesystem is that after a
>> crash or power loss, a journal replay on next mount will bring the
>> metadata into a consistent state.
>
>     Not an actual argument within the discussion, but an interesting
> observation on a fine distinction:
>
>     It's interesting to note that there's a difference here between
> journalling and CoW filesystems. A journalling FS needs a journal
> replay to become consistent. A CoW FS is _always_ consistent, by
> design. Now, btrfs has a log that should be replayed after an unclean
> shutdown, but that's all about the data that got written within the
> current transaction that wasn't committed,

In fact, log tree of btrfs is only used to speedup fsync. And there is a 
"notreelog" mount option to disable such log tree, if one uses it, fsync 
performance will just drop to the level of sync.

So it's just an optimization, although it's already quite away from the 
original topic, I think the best method for btrfs to improve fsync 
performance is to introduce something like ext*:

Per-file extent map tree.


The reason btrfs is slow on fsync is, file extent and inode info are all 
stored in the same tree(fs tree or subvolume tree).

To only fsync a inode, it's impossible only fsync all its file extents, 
but to sync the whole tree, which may just as slow as a full sync.

That's why log tree is introduced, only writeback file extents of an 
inode and record its metadata changes into the log tree.
And performance test result also supports this.


But other filesystem, at least ext* uses a better solution, each inode 
(no matter regular file or dir) has its own tree to record its file 
extents or dir entries.
Making fsync quite easy and straightforward.

If btrfs follows the same design, at least the random RW performance may 
have a boost and simplify the fsync codes.

Thanks,
Qu


> rather than about FS
> metadata consistency. This means that a read-only mount of btrfs can
> _actually_ be read-only, not modifying any of the data on the disk,
> whereas a read-only mount of a journalling FS _must_ modify the disk
> data after an unclean shitdown, in order to be useful (because the FS
> isn't consistent without the journal replay).
>
>     Hugo.
>

Re: shall distros run btrfsck on boot?

[Austin S Hemmelgarn]

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

On 2015-11-24 17:26, Eric Sandeen wrote:
> On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:
>
>> if the system was
>> shut down cleanly, you're fine barring software bugs, but if it
>> crashed, you should be running a check on the FS.
>
> Um, no...
>
> The *entire point* of having a journaling filesystem is that after a
> crash or power loss, a journal replay on next mount will bring the
> metadata into a consistent state.
>
OK, first, that was in reference to BTRFS, not ext4, and BTRFS is a COW 
filesystem, not a journaling one, which is an important distinction as 
mentioned by Hugo in his reply.  Second, there are two reasons that you 
should be running a check even of a journaled filesystem when the system 
crashes (this also applies to COW filesystems, and anything else that 
relies on atomicity of write operations for consistency):

1. Disks don't atomically write anything bigger than a sector, and may 
not even atomically write the sector itself.  This means that it's 
possible to get a partial write to the journal, which in turn has 
significant potential to put the metadata in an inconsistent state when 
the journal gets replayed (IIRC, ext4 has a journal_checksum mount 
option that is supposed to mitigate this possibility).  This sounds like 
something that shouldn't happen all that often, but on a busy 
filesystem, the probability is exactly proportionate to the size of the 
journal relative to the size of the FS.

2. If the system crashed, all code running on it immediately before the 
crash is instantly suspect, and you have no way to know for certain that 
something didn't cause random garbage to be written to the disk.  On top 
of this, hardware is potentially suspect, and when your hardware is 
misbehaving, then all bets as to consistency are immediately off.


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

Re: shall distros run btrfsck on boot?

[Martin Steigerwald]

Am Mittwoch, 25. November 2015, 07:32:34 CET schrieb Austin S Hemmelgarn:
> On 2015-11-24 17:26, Eric Sandeen wrote:
> > On 11/24/15 2:38 PM, Austin S Hemmelgarn wrote:
> >> if the system was
> >> shut down cleanly, you're fine barring software bugs, but if it
> >> crashed, you should be running a check on the FS.
> > 
> > Um, no...
> > 
> > The *entire point* of having a journaling filesystem is that after a
> > crash or power loss, a journal replay on next mount will bring the
> > metadata into a consistent state.
> 
> OK, first, that was in reference to BTRFS, not ext4, and BTRFS is a COW
> filesystem, not a journaling one, which is an important distinction as
> mentioned by Hugo in his reply.  Second, there are two reasons that you
> should be running a check even of a journaled filesystem when the system
> crashes (this also applies to COW filesystems, and anything else that
> relies on atomicity of write operations for consistency):
> 
> 1. Disks don't atomically write anything bigger than a sector, and may
> not even atomically write the sector itself.  This means that it's
> possible to get a partial write to the journal, which in turn has
> significant potential to put the metadata in an inconsistent state when
> the journal gets replayed (IIRC, ext4 has a journal_checksum mount
> option that is supposed to mitigate this possibility).  This sounds like
> something that shouldn't happen all that often, but on a busy
> filesystem, the probability is exactly proportionate to the size of the
> journal relative to the size of the FS.
> 
> 2. If the system crashed, all code running on it immediately before the
> crash is instantly suspect, and you have no way to know for certain that
> something didn't cause random garbage to be written to the disk.  On top
> of this, hardware is potentially suspect, and when your hardware is
> misbehaving, then all bets as to consistency are immediately off.

In the case of shaky hardware a fsck run can report bogus data, i.e. problems 
where they are none or vice versa. If I suspect defect memory or controller I 
would check the device on different hardware only. Especially on attempts to 
repair any possible issues.


-- 
Martin

Re: shall distros run btrfsck on boot?

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/23/15 11:02 PM, Christoph Anton Mitterer wrote:
> Hey.
> 
> Short question since that came up on debian-devel.
> 
> Now that btrfs check get's more and more useful, are the
> developers going to recommend running it periodically on boot (of
> course that wouldn't work right now, as it would *always* check)?

Running fsck on boot is a holdover from an era where non-journaling
file systems were the norm.  It persists in the ext* world mostly due
to inertia, but it shouldn't be run on boot with ext3 or ext4 either.
 As Eric noted, fsck.xfs is a no-op.  We have something similar for
btrfs and have no intention of ever running fsck on boot with btrfs
except in the case of a mount failure of the root file system.

> Plus... is btrfs check (without any arguments) non-desctructive, or
> are there corner-cases where it may lead to any changes on the
> devices?

I haven't reviewed it in detail, but a quick glance makes it look like
it will, minimally, create transactions even in check-only mode.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQIcBAEBCAAGBQJWWdvZAAoJEB57S2MheeWyH9IP/3fYiURQ//xy4QHxUqztiR2h
NrX+I2n7cnaK3jxhgSQ4snFMzQqxpyjDdV3bTy6kqfBIhvrXKGVQdyFG0SV1MNuJ
WJuJYCzQa81mDP3G2T3I3sN7oFndIctKaDNBJ5VVCes/W7sFm3JTTfRRmPm7rhNw
GeFTnKFaZ39Lc53VOR7nX3vDKeGWzyyl2WGYYQ2uq7CKIn3jW1Pi5PKEysq21d8W
zsDjMh3PfI/TkI4BvNZkyoQaQPaMPZrK0rvY0ke3ScKh5W9MO9zZwcheT79gBRS/
MPtyOdWVtslDwdurgPyi9fX4bFlPQ6vqBy3evFeYBhuujypX49T8xZGUSIWUvXli
ElGm80S/+UWGWMl968BcoAp/rrQTfnZcYPHV4YZaeRRwdli5z82gRQsB5OYsQd1w
AlKJ3uq5mFu/qbWYgM3d51tr+OwZOSCDp9Ofj41Da7P1YmGDC10BP8hlm/YiDP91
sRCPF8Y9vy9F6wkCH0xX416CoR/jmB1xKgNiVs64laMfznLBprgGxpTh0/Eh6jjS
aXvtPyJjsidjIXBygzXVDHcSkZT6B881wWhKmDhLiSd5iQqfEnelbOB4gP7ew92X
QbATRfjIPqCPfLS3S2mOlewq+IbFBvX6TkDzqyGjyST66h3MgayD1nADNGMOauV7
aFaeWgGFGM1gcqDS/7vY
=eiA7
-----END PGP SIGNATURE-----

Re: shall distros run btrfsck on boot?

[Qu Wenruo]

Jeff Mahoney wrote on 2015/11/28 11:52 -0500:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 11/23/15 11:02 PM, Christoph Anton Mitterer wrote:
>> Hey.
>>
>> Short question since that came up on debian-devel.
>>
>> Now that btrfs check get's more and more useful, are the
>> developers going to recommend running it periodically on boot (of
>> course that wouldn't work right now, as it would *always* check)?
>
> Running fsck on boot is a holdover from an era where non-journaling
> file systems were the norm.  It persists in the ext* world mostly due
> to inertia, but it shouldn't be run on boot with ext3 or ext4 either.
>   As Eric noted, fsck.xfs is a no-op.  We have something similar for
> btrfs and have no intention of ever running fsck on boot with btrfs
> except in the case of a mount failure of the root file system.
>
>> Plus... is btrfs check (without any arguments) non-desctructive, or
>> are there corner-cases where it may lead to any changes on the
>> devices?
>
> I haven't reviewed it in detail, but a quick glance makes it look like
> it will, minimally, create transactions even in check-only mode.

This seems interesting.

Any clue to enhance?

Thanks,
Qu
>
> - -Jeff
>
> - --
> Jeff Mahoney
> SUSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2
>
> iQIcBAEBCAAGBQJWWdvZAAoJEB57S2MheeWyH9IP/3fYiURQ//xy4QHxUqztiR2h
> NrX+I2n7cnaK3jxhgSQ4snFMzQqxpyjDdV3bTy6kqfBIhvrXKGVQdyFG0SV1MNuJ
> WJuJYCzQa81mDP3G2T3I3sN7oFndIctKaDNBJ5VVCes/W7sFm3JTTfRRmPm7rhNw
> GeFTnKFaZ39Lc53VOR7nX3vDKeGWzyyl2WGYYQ2uq7CKIn3jW1Pi5PKEysq21d8W
> zsDjMh3PfI/TkI4BvNZkyoQaQPaMPZrK0rvY0ke3ScKh5W9MO9zZwcheT79gBRS/
> MPtyOdWVtslDwdurgPyi9fX4bFlPQ6vqBy3evFeYBhuujypX49T8xZGUSIWUvXli
> ElGm80S/+UWGWMl968BcoAp/rrQTfnZcYPHV4YZaeRRwdli5z82gRQsB5OYsQd1w
> AlKJ3uq5mFu/qbWYgM3d51tr+OwZOSCDp9Ofj41Da7P1YmGDC10BP8hlm/YiDP91
> sRCPF8Y9vy9F6wkCH0xX416CoR/jmB1xKgNiVs64laMfznLBprgGxpTh0/Eh6jjS
> aXvtPyJjsidjIXBygzXVDHcSkZT6B881wWhKmDhLiSd5iQqfEnelbOB4gP7ew92X
> QbATRfjIPqCPfLS3S2mOlewq+IbFBvX6TkDzqyGjyST66h3MgayD1nADNGMOauV7
> aFaeWgGFGM1gcqDS/7vY
> =eiA7
> -----END PGP SIGNATURE-----
> --
> 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: shall distros run btrfsck on boot?

[Austin S Hemmelgarn]

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

On 2015-11-28 11:52, Jeff Mahoney wrote:
> On 11/23/15 11:02 PM, Christoph Anton Mitterer wrote:
>> Hey.
>>
>> Short question since that came up on debian-devel.
>>
>> Now that btrfs check get's more and more useful, are the
>> developers going to recommend running it periodically on boot (of
>> course that wouldn't work right now, as it would *always* check)?
>
> Running fsck on boot is a holdover from an era where non-journaling
> file systems were the norm.  It persists in the ext* world mostly due
> to inertia, but it shouldn't be run on boot with ext3 or ext4 either.
>   As Eric noted, fsck.xfs is a no-op.  We have something similar for
> btrfs and have no intention of ever running fsck on boot with btrfs
> except in the case of a mount failure of the root file system.
The bit about ext* is debatable, the code doesn't appear to do any 
automatic repairs on an online filesystem like XFS does (and BTRFS does 
when you scrub it), which would indicate to me that it should be run, 
but not forced on boot for ext3/4, assuming the FS is configured sanely 
(which means on the systems I manage, it only gets run at most once 
every 24 hours unless I break into the boot sequence and force it manually).
>
>> Plus... is btrfs check (without any arguments) non-desctructive, or
>> are there corner-cases where it may lead to any changes on the
>> devices?
>
> I haven't reviewed it in detail, but a quick glance makes it look like
> it will, minimally, create transactions even in check-only mode.
I agree with Qu here, if this is the case, it's a bug that needs to be 
fixed.



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

Re: shall distros run btrfsck on boot?

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/29/15 8:59 PM, Qu Wenruo wrote:
> 
> 
> Jeff Mahoney wrote on 2015/11/28 11:52 -0500: On 11/23/15 11:02
> PM, Christoph Anton Mitterer wrote:
>>>> Hey.
>>>> 
>>>> Short question since that came up on debian-devel.
>>>> 
>>>> Now that btrfs check get's more and more useful, are the 
>>>> developers going to recommend running it periodically on
>>>> boot (of course that wouldn't work right now, as it would
>>>> *always* check)?
> 
> Running fsck on boot is a holdover from an era where non-journaling
> file systems were the norm.  It persists in the ext* world mostly
> due to inertia, but it shouldn't be run on boot with ext3 or ext4
> either. As Eric noted, fsck.xfs is a no-op.  We have something
> similar for btrfs and have no intention of ever running fsck on
> boot with btrfs except in the case of a mount failure of the root
> file system.
> 
>>>> Plus... is btrfs check (without any arguments) 
>>>> non-desctructive, or are there corner-cases where it may
>>>> lead to any changes on the devices?
> 
> I haven't reviewed it in detail, but a quick glance makes it look 
> like it will, minimally, create transactions even in check-only 
> mode.
> 
>> This seems interesting.
> 
>> Any clue to enhance?

My glance wasn't close enough.  We only start a transaction after we
check and repair is enabled.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJWXKM2AAoJEB57S2MheeWynW4QAJBHbn8Wk+z4hRVfdtg2J6Ot
v3HMaI3kto0Pg1fi87pQKJd3ET/p1ovdTQr2awCBr9hS3Pe5cPGF8Giv+LstWW5G
LWWDaZDYqIJOGx69cwgiYIHxzMf/xn3xoovkrc63b8XjiZa3kUgMbb0cxtnNpXGE
2pa0das4ePZQ54OEfJvOdtdAhwMot1CV9UQaPm1DVJ8eQLAIvQKo4TFtv2y7FlNk
eVfqcK2rM0SHmrx1IcHtd6EBG7yK0zCqPiFLBEU8Zkx3dFDTqsrsa1F2Vgnu7Pm8
LUZekSIUarqQcmM6xZpuZdA+7aOJ2pcCx2aoaYe34QK6U1YHD/Tb+tJNusMMUUdp
z/0NjKmj4ONasbZ9ttZWg4FdDi2eVIRSZ7mYxSv6Gblo7iU/k8WSCzr/VZrnMzXG
idEc9hUUykWdDLYJ7q6EP3/2rApjw/lxLD7peX/+ew9v9ddISbCI+qWO/+ocnPkH
0+v/FkWMFEoaZL5yRkJLfAPNnT4cGEu5n3hjy5Pgxc+1D+eZU+0EtR+0kd8iO/LH
+qrz9RcVLKnPk3dMP6bAznqWz/pmry213AFRl4kTJsv5XDt9oSz4BmhKGU+zG+v6
JPXme3Fl/8GSaRVzTbQ+ALC5vxBL8oFQaV9jY8GA8d24dSXWqDYFLvIjtUNek/r2
gT7Z2612ZTceYX4oFOuk
=32+d
-----END PGP SIGNATURE-----