On 2015-11-24 17:26, Eric Sandeen wrote:
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):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.
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.
smime.p7s
Description: S/MIME Cryptographic Signature
