Re: [PATCH 2/2] btrfs: do not write corrupted metadata blocks to disk

[Duncan <1i5t5.duncan@cox.net>]

Nicholas D Steeves posted on Wed, 06 Apr 2016 00:04:36 -0400 as excerpted:

> Ah, that's exactly what I was looking for!  Thank you.  It took forever,
> and brought me back to what it was like to fsck large ext2 volumes.  Is
> btrfs check conceptually identical to a read-only fsck of a ext2 volume?
> If now how does it defer?

That question had me confused for a moment as I couldn't figure out what 
was "deferred", until I realized you must have meant "differ". =:^)

At a suitably high level, yes, btrfs check (without --repair) is 
comparable to a read-only fsck of an ext* volume.  They're both quite 
deep and thorough checks of their respective filesystems.

But while ext2 had no journal and thus required such a deep fsck on 
reboot to recover after a bad shutdown, the later generations had a 
journal and avoided that, tho running an occasional fsck was still 
recommended.  What they run automatically (on boot) is a very brief check 
that just checks some basics and that the filesystem looks like it 
should, replaying the journal if shutdown wasn't safely done, but nothing 
very thorough at all.

And btrfs, being an atomic operation copy-on-write (cow) filesystem, is 
to a journaled filesystem like ext3/4, what a journaled filesystem like 
ext3/4 is to an earlier unjournaled filesystem like ext2.  Which is why 
btrfs check doesn't normally need to be run -- because in general, the 
atomic cow nature of btrfs means that a commit is done atomically, you 
either get the state of the previous commit, or of the new one.  There's 
no way to get a half-way state where only part of the data was written, 
which was the problem ext2 had, that the ext3 and later ext4 journal was 
designed to alleviate, but that an atomic cow filesystem such as btrfs 
does away with entirely.

(Tho btrfs does have a journal, its use is far more limited.  Normally, 
commits happen only every 30 seconds or so, and the btrfs journal simply 
replays any fsynced file changes between commits so they still hit the 
filesystem in the case of a crash before a later commit did it the normal 
way.  IOW, it's only a shortcut to faster fsyncs, which would otherwise 
force a full filesystem commit before returning, much as they did on 
ext3.  But even without that replay, a btrfs should be self-consistent to 
one of the two latest commits, with only the fsyncs done between commits 
lost if the log isn't replayed at all.)

Of course all that assumes no critical bugs.  There's a reason btrfs is 
still considered stabilizing, not fully stable and mature yet, as there 
are still bugs being found and fixed that prevent this ideal from being 
reality in more cases than we'd like, tho the filesystem is in general 
stable enough for many to use daily, as many including myself do, as long 
as they have backups just in case, and their world won't end if they 
actually have to use them.

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