From owner-freebsd-stable@FreeBSD.ORG Tue Aug 30 02:23:39 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5346516A41F for ; Tue, 30 Aug 2005 02:23:39 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-3.paradise.net.nz (bm-3a.paradise.net.nz [202.0.58.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D031C43D46 for ; Tue, 30 Aug 2005 02:23:38 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-2.paradise.net.nz (smtp-2a.paradise.net.nz [202.0.32.195]) by linda-3.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IM00087OJZCYY@linda-3.paradise.net.nz> for freebsd-stable@freebsd.org; Tue, 30 Aug 2005 14:23:37 +1200 (NZST) Received: from [192.168.1.11] (218-101-13-128.paradise.net.nz [218.101.13.128]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id 661099ECD9; Tue, 30 Aug 2005 14:18:41 +1200 (NZST) Date: Tue, 30 Aug 2005 14:18:40 +1200 From: Mark Kirkwood In-reply-to: <20050830011106.GF1462@drjekyll.mkbuelow.net> To: Matthias Buelow Message-id: <4313C200.9090605@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) 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> <20050830011106.GF1462@drjekyll.mkbuelow.net> Cc: freebsd-stable@freebsd.org Subject: Re: Sysinstall automatic filesystem size generation. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 02:23:39 -0000 Matthias Buelow wrote: > >>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? LOL, well quite often - nt4 seemed to specialize in this, win2k and winxp (particularly 2k) however, seem much better... > 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. > But otherwise, thanks for a very informative post. Hmm, I think OSX does something like this too. Funnily enough, I have never lost files while using FreeBSD, even tho I'm using ATA disks with the write cache enabled - and I have had power loss situations. The robustness was one of the things that persuaded me to switch from (Redhat 7.3/8.0 I think) to FreeBSD (4.6 I think). However that is ancient history, If everyone is working out how to manipulate the write cache on-demand, then I guess FreeBSD needs to as well...(not volunteering... probably a bit out of my league). Cheers Mark