the worst scenario of ext3 after abnormal powerdown

[Matija Nalis]

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
> system.

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.