linux-ext4 - Re: What to do when the journal checksum is incorrect

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 May 2008 17:28:30 -0400
From:	Ric Wheeler <ricwheeler@...il.com>
To:	Andreas Dilger <adilger@....com>
CC:	Theodore Tso <tytso@....EDU>, linux-ext4@...r.kernel.org,
	Girish Shilamkar <Girish.Shilamkar@....com>
Subject: Re: What to do when the journal checksum is incorrect

Andreas Dilger wrote:
> On May 25, 2008  07:38 -0400, Theodore Ts'o wrote:
>> Well, what are the alternatives?  Remember, we could have potentially
>> 50-100 megabytes of stale metadata that haven't been written to
>> filesystem.  And unlike ext2, we've deliberately held back writing
>> back metadata by pinning it so, things could be much worse.  So let's
>> tick off the possibilities:
>>
>> * An individual data block is bad --- we write complete garbage into
>>   the filesystem, which means in the worst case we lose 32 inodes
>>   (unless that inode table block is repeated later in the journal), 1
>>   directory block (causing files to land in lost+found), one bitmap
>>   block (which e2fsck can regenerate), or a data block (if data=jouranalled).
>>
>> * A journal descriptor block is bad --- if it's just a bit-flip, we
>>   could end up writing a data block in the wrong place, which would be
>>   bad; if it's complete garbage, we will probably assume the journal
>>   ended early, and leave the filesystem silently badly corrupted.
>>
>> * The journal commit block is bad --- probably we will just silently
>>   assume the journal ended early, unless the bit-flip happened exactly
>>   in the CRC field.
>>
>> The most common case is that one or more individual data blocks in the
>> journal are bad, and the question is whether writing that garbage into
>> the filesystem is better or worse than aborting the journal right then
>> and there.
> 
> You are focussing on the case where 1 or 2 filesystem blocks in the
> journal are bad, but I suspect the real-world cases are more likely to
> be 1 or 2MB of data are bad, or more.  Considering that a disk sector
> is at least 4 or 64kB in size, and problems like track misalignment
> (overpowered seek), write failure (high-flying write), or device cache
> reordering problems will result in a large number of bad blocks in the
> journal, I don't think 1 or 2 filesystem is a realistic failure scenario
> anymore.

Disk sectors are still (almost always) 512 bytes today, but the industry is 
pushing hard to get 4k byte sectors out since that has a promise of getting 
better data protection and denser layout. Disk arrays have internal "sectors" 
that can be really big (64k or bigger).

What seems to be most common is a small number of bad sectors that will be 
unreadable (IO errors on read). I would be surprised to see megabytes of 
continuous errors, but you could see 10's of kilobytes.

What the checksums will probably be most useful in catching is problems with 
memory parts - either non-ECC DRAM in your server, bad DRAM in the disk cache 
itself, etc. The interesting thing about these errors is that they will tend to 
repeat (depending on where that stuck bit is) and you can see it all over the place.

One thing that will be really neat is to actually put in counters to track the 
rate and validate these assumptions.


ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html