Hi, I have seen and heard many cases of ext3 corrupted after abnormal powerdown (e.g. missing all the files in one directory). yes, UPS should help, but wonder what kind of worst scenario will ext3 present after powerdown. 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? 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. thanks, -- Pengcheng
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.
On Mon, Oct 23, 2006 at 10:27:20PM +0800, Pengcheng Zou wrote:> thanks a lot for the explanation. so if i understand it clearly, to > get a reliable data storage, i need turn off write cache or enable > barrier. both methods depend on the hardware. so how to know whether a > disk or drive support write cache? how to turn off write cache (i know > hdparm -W0 for IDE, but how to turn off write cache of SCSI drive?)?maybe http://scsirastools.sourceforge.net/ ? also see: http://www-dt.e-technik.uni-dortmund.de/~ma/linux/kernel/safe-write-caches.html -- Opinions above are GNU-copylefted.