From owner-freebsd-stable@FreeBSD.ORG Sat Jul 16 16:22:05 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 B0CD116A41C for ; Sat, 16 Jul 2005 16:22:05 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44C5843D46 for ; Sat, 16 Jul 2005 16:22:05 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j6GGM0dC055151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jul 2005 12:22:02 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4) with ESMTP id j6GGLsuJ018161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Jul 2005 12:21:54 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4/Submit) id j6GGLrSm018160; Sat, 16 Jul 2005 12:21:53 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Matthias Buelow In-Reply-To: <20050716141630.GB752@drjekyll.mkbuelow.net> References: <20050715224650.GA48516@outcold.yadt.co.uk> <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> <20050716133710.GA71580@outcold.yadt.co.uk> <20050716141630.GB752@drjekyll.mkbuelow.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 16 Jul 2005 12:21:52 -0400 Message-Id: <1121530912.17757.32.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process 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: Sat, 16 Jul 2005 16:22:05 -0000 On Sat, 2005-07-16 at 16:16 +0200, Matthias Buelow wrote: > David Taylor wrote: > > >No. I'm just asking if you know of ANY ata drives that will wait for the > >cache to be flushed before claiming the disable cache command has > >succeeded. I don't, but I haven't looked. > > I don't know either. I assume that they do. Does it matter? > I mean, I'm not suggesting a frivolous new theory that is highly > speculative and warrants a lengthy debate on its purported merits. > What I described is common practice on Windows, Linux and probably > a few other systems and I would think that they're not doing this > for nothing. And, frankly, I'm a bit astonished that the FreeBSD > (community) seems to be so ignorant of well-known measures for > improving data safety on consumer-grade desktop hardware. Does that > mean that FreeBSD is deemed generally unsuited for desktop and > laptop use and should be reserved for servers with the appropriate > (expensive) hardware? I hope not. I recall reading on freebsd-current that Scott Long is working on adding journalling support to FFS. Perhaps you'd like to direct your input to him instead of rehashing it repeatedly on here, which is the wrong outlet for such discussion anyway: by definition, CURRENT, not STABLE will get a new feature like journalling, and so discussing the ins and outs of it on freebsd-current would seem more apropos. (Plus, I'd hate to see him implement something only for you to declare it to be "the wrong way to do things." Better to get your 2p in now.:) Reagrding your question of "does that mean that FreeBSD is deemed generally unsuited for desktop and laptop use," I can speak only from experience. I run 6-CURRENT on an ATA system using softupdates on my desktop, and have been doing so for quite some time. I've seen through quite a few periods of extreme growing pains for CURRENT, with seemingly random panics and mystery crashes at times. (Who can forget the dark days of the ULE + PREEMPTION instability?) Add to the mix that my neighbourhood has pretty flaky power, with a tendency for short interruptions at the first whiff of bad weather. This all adds up to a good smattering of reboots at inopportune times (like when doing buildworlds or large portupgrade sessions:). Despite that, I have never EVER had a problem with data consistency on my file systems. (The only problem I have had is when I added an ATA controller card one time and forgot to disable its RAID BIOS, which promptly spammed over my geom_mirror metadata.:) If softupdates were as unsafe as you often hint, I'm surprised that I haven't lost a file system by now. (I would also expect to hear from the field a lot more clamour about how unsafe it is, and that, in fact, the sky was indeed falling.) I guess I must be amazingly lucky and should start playing the lottery right now. :-) The main inconvenience I have with panics or outages is the fsck times on reboot. (Actually, what I find to be more inconvenient is the resynchronisation time needed for my geom_mirror, which takes a lot longer than a fsck.) I understand that fsck delays for large file systems is the major impetus behind the journalling work, not as a fix for a perceived data consistency problem. Cheers, Paul. PS: I also use softupdates on my NetBSD systems, again without problems. I've also used LFS on NetBSD at times, but have always ended up abandoning it due to performance and severe data reliability problems. (To be clear, though, I'm not sure LFS was deemed to be for "production use," at least not the times I tried it.) -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa