the worst scenario of ext3 after abnormal powerdown
mnalis-ml at voyager.hr
Sat Oct 21 11:43:26 UTC 2006
On Sat, Oct 21, 2006 at 07:02:53AM +0800, Pengcheng Zou wrote:
> messed up meta data has been seen in many cases, for example, the
> in-direct block of one inode contains garbage, which causes the automatic
> fsck failed to work and user has to repair the file system manually (and
> always result in some missing files). should I blame ext3 for it? or
> should I just turn off the disk write cache?
In recent 2.6.x you can mount ext3 with "-o barrier=1", and you should be
able to safely use disks with write cache on (if the disks support it,
watch dmesg for "JBD: barrier-based sync failed" errors if not supported)
read Documentation/block/barrier.txt for more info.
> it seems Windows NTFS has less such problem than ext3, and no matter
> it's the problem of ext3 or mis-configured hardware, this behavior is
> really causes lots of people to doubt the stability of Linux file
It would be nice to know why "barrier=1" is not the default (to be safe by
default, like with journal=ordered instead of journal=writeback) on ext3 ?
(it is on by default on XFS for example)
Also interesting question on http://lkml.org/lkml/2005/12/18/99
"... But if you want a different raid level you should ask the ext3
developers if there is a reason they don't call blkdev_issue_flush if
barriers aren't supported."
Opinions above are GNU-copylefted.
More information about the Ext3-users