From owner-freebsd-current@FreeBSD.ORG Mon Jul 26 18:47:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B77E16A4CE; Mon, 26 Jul 2004 18:47:58 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94DC243D64; Mon, 26 Jul 2004 18:47:57 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6QIsdwj083132; Mon, 26 Jul 2004 12:54:39 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i6QIsdsO083129; Mon, 26 Jul 2004 12:54:39 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Mon, 26 Jul 2004 12:54:39 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: Brian Fundakowski Feldman In-Reply-To: <20040726181821.GB96815@green.homeunix.org> Message-ID: <20040726125328.L32601@pooker.samsco.org> References: <1090718450.2020.4.camel@illusion.com> <200407251112.46183.doconnor@gsoft.com.au> <20040726152151.GC1473@green.homeunix.org> <20040726175219.GA96815@green.homeunix.org> <20040726181821.GB96815@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org cc: bugghy Subject: Re: magic sysrq keys functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2004 18:47:58 -0000 On Mon, 26 Jul 2004, Brian Fundakowski Feldman wrote: > On Mon, Jul 26, 2004 at 12:15:02PM -0600, Scott Long wrote: > > On Mon, 26 Jul 2004, Brian Fundakowski Feldman wrote: > > > On Mon, Jul 26, 2004 at 11:49:55AM -0600, Scott Long wrote: > > > > On Mon, 26 Jul 2004, Brian Fundakowski Feldman wrote: > > > > B> On Sun, Jul 25, 2004 at 09:23:36PM +0000, bugghy wrote: > > > > > > Yeah but it sometimes "freezes" (no reboot) ... and I'd rather umount my > > > > > > filesystems before rebooting. > > > > > > > > > > SoftUpdates guarantess that your file systems will not get corrupt. > > > > > > > > > > > > > This isn't entirely correct. Softupdates guarantees that you won't get > > > > corruption due to metadata pointing to invalid or stale data blocks. > > > > That's not the same as guaranteeing that there won't be any corruption. > > > > Write caching on the drive combined with an in-opportune power loss or > > > > other failure can easily leave you with corrupt or incomplete metadata > > > > and/or data blocks. A panic while metadata is being committed to disk can > > > > also leave the metadata highly inconsistent and prone to corruption. > > > > This isn't to say the SU is bad or that other strategies are necessarily > > > > better, just that there are definite risks. > > > > > > If you just want to generalize it, you can say that "SoftUpdates > > > guarantees that your file systems will not get corrupt due to just > > > software errors." I don't particularly think not having UPS is a > > > good idea, but those can fail, and even so the ordering is such > > > that a truncated inode won't result in a truly corrupt filesystem, > > > and the inode doesn't get written until its contents are written > > > out. > > > > > > Also, hw.ata.wc really shouldn't default to 1. > > > > > > > GAH! No, please don't start this war again! The last time that we tried > > turning this off in a release (4.1 IIRC), were were plagqued by months of > > earthquakes, plagues, and deaths of first-born youngsters. I 100% agree > > that write caching in ATA is not compatible with data integrety, but the > > ATA marketting machine has convinced us that cached+untagged speed is > > better than uncached+tagged safety. C'est la vie, or so they say here. > > I think it would be prudent to add a nice fat "WARNING:" printf to the > boot process. It's really not obvious that FreeBSD defaults to having > your hard drives run "unsafely," even though it is usually faster. > I think that this was discussed too. The problem is that Linux and Windows also silently default to having it on, and breaking from that status quo causes too much haertburn. Scott