Date: Tue, 30 Aug 2005 03:11:06 +0200 From: Matthias Buelow <mkb@incubus.de> To: Mark Kirkwood <markir@paradise.net.nz> Cc: freebsd-stable@freebsd.org Subject: Re: Sysinstall automatic filesystem size generation. Message-ID: <20050830011106.GF1462@drjekyll.mkbuelow.net> In-Reply-To: <4313AB8D.4010807@paradise.net.nz> References: <20050829120415.GA1462@drjekyll.mkbuelow.net> <200508291836.j7TIaVEk013147@gw.catspoiler.org> <20050829185933.GB1462@drjekyll.mkbuelow.net> <431362ED.9030800@mac.com> <20050829204714.GC1462@drjekyll.mkbuelow.net> <43137AFB.9060304@mac.com> <20050829215613.GD1462@drjekyll.mkbuelow.net> <431390A0.5080007@mac.com> <20050830002051.GE1462@drjekyll.mkbuelow.net> <4313AB8D.4010807@paradise.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Kirkwood wrote: >Would you be happy if the handbook section added a caution, or referred >to the section that discusses the write cache? Yes, that would inform the user. >(FWIW - I have seen Linux + ext3 systems destroyed by power failure >because the admins refused to disable write caching on ATA drives - >Neither journelling or softupdates is much help if the HW is kidding you >about write acknowledgment). >From what I understand from googling around on that issue, the write-barrier stuff should make that much more unlikely. Of course there could be the situation that it was a kernel that did not (properly) support write-barriers yet, or the Linux implementation has/had bugs (not too unlikely), or the disk was so broken that even the flushing workaround strategies were ignored or it otherwise didn't properly flush it, etc. But they're at least trying to cope with the issue. BTW., when have you last seen a broken NTFS? While I don't do Windows much, I have had quite a few crashes on Windows (2000, XP) over the years on various machines, and I always asked myself how it could be that the system is up almost immediately (probably due to log replay) with no discernible filesystem damage. Windows (NT) has been doing the write barrier flush tricks (disabling-/ reenabling the cache for flushing it) for longer than Linux and I would think that this contributes to the fault resilience of NTFS. Not that I would imply that NTFS can't be corrupted, of course. mkb.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050830011106.GF1462>