Re: EXT3 File System Corruption 2.6.34

From: Valdis . Kletnieks
Date: Mon Jun 07 2010 - 17:04:32 EST


On Mon, 07 Jun 2010 14:45:38 MDT, Jeffrey Merkey said:
> Still seeing file system corruption after journal recovery in EXT3.

Are you getting bit by one of these mount options? (from 'man mount')
There were changes a few releases ago, might want to check what
your kernel build defaulted it to in your 2.6.34.

data={journal|ordered|writeback}
Specifies the journalling mode for file data. Metadata is
always journaled. To use modes other than ordered on the root
filesystem, pass the mode to the kernel as boot parameter, e.g.
rootflags=data=journal.

journal
All data is committed into the journal prior to being
written into the main filesystem.

ordered
This is the default mode. All data is forced directly
out to the main file system prior to its metadata being
committed to the journal.

writeback
Data ordering is not preserved - data may be written into
the main filesystem after its metadata has been committed
to the journal. This is rumoured to be the highest-
throughput option. It guarantees internal filesystem
integrity, however it can allow old data to appear in
files after a crash and journal recovery.

barrier=0 / barrier=1
This enables/disables barriers. barrier=0 disables it, barâ??
rier=1 enables it. Write barriers enforce proper on-disk orderâ??
ing of journal commits, making volatile disk write caches safe
to use, at some performance penalty. The ext3 filesystem does
not enable write barriers by default. Be sure to enable barriâ??
ers unless your disks are battery-backed one way or another.
Otherwise you risk filesystem corruption in case of power failâ??
ure.

Attachment: pgp00000.pgp
Description: PGP signature