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. _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
