Re: shall distros run btrfsck on boot?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

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