Responding to ext4 journal corruption [LWN.net]

Responding to ext4 journal corruption

Posted Jun 1, 2008 22:09 UTC (Sun) by jlokier (guest, #52227)
In reply to: Responding to ext4 journal corruption by jzbiciak
Parent article: Responding to ext4 journal corruption

Another way, which doesn't pin blocks and prevent their reallocation, is to keep track of
dependencies in the journal: transaction 3 _depends_ on transaction 2, because it uses blocks
which are repurposed in transaction 2.  So there should be a note in transaction 3 saying "I
depend on T2".

During replay, if transaction 2 fails due to bad checksum, transaction 3 will be rejected due
to the dependency.  Transaction 4 may be fine, etc.

(The same dependencies can be converted to finer-grained barriers too - e.g. to optimise ext4
on software RAID.)

Some RAM is needed to keep track of the dependencies, until commits are known to have hit the
platters.  If it's a problem, this can be bounded with some hashed approximation akin to a
Bloom filter.

(Log in to post comments)

Responding to ext4 journal corruption

Posted Jun 9, 2008 3:26 UTC (Mon) by efexis (guest, #26355) [Link]

This is what first came to my mind, but if data has been written, but metadata saying what
this data is gets discarded, the new data could be misinterpreted as what the previous
metadata said it was (such as believing it to be more metadata pointing to blocks on the disk,
but it's actually an image). I guess the solution here would be to zero any pointers to
metadata first (or settings a 'corrupt' or 'deleted' flag on the metadata sector itself) and
making sure that's reached the disk before writing the data. Of course this can slow things
down as you have to write to the metadata block an extra time per update.

I think the snapshotting way is the only way forward; if you never get rid of something until
certain the new one works (ie, has completely reached the disc) then it doesn't matter what
you do or when... you'll always have at least one working version. Large writes would start
failing when your disc is nearing full, but with todays drive sizes, we're more concerned with
losing 500G of data than filling it.