From owner-cvs-all Tue Dec 7 23:36:50 1999 Delivered-To: cvs-all@freebsd.org Received: from mass.cdrom.com (castles551.castles.com [208.214.165.115]) by hub.freebsd.org (Postfix) with ESMTP id 29D7E14D12; Tue, 7 Dec 1999 23:36:46 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA04106; Tue, 7 Dec 1999 23:38:57 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912080738.XAA04106@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: mjacob@feral.com Cc: Mike Smith , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_shutdown.c In-reply-to: Your message of "Tue, 07 Dec 1999 23:32:14 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Dec 1999 23:38:57 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > > > Yes, it is in fact. If you cannot guarantee data integrity, you shouldn't > > > be running on it. If you have to run on it, don't expect data integrity. > > > > I thought your argument was "we ought to work properly where it's > > possible, rather than pursue some golden ideal of perfection"? > > No- not quite. We should claim to support sane hardware, but shrug and > hand the user the bullets if they want to end it all for themselves. Given that it's not hard to "support" this hardware in a functional fashion, I think the effort is better than taking a bullet in the back from our users. > > > (okay, so it's a couple of buffers at shutdown- in any case, perhaps the > > > driver that sees Synchronize Cache not working should do something else- > > > maybe calculate the Pareto for the first occurence of a y3k bug) > > > > You could just delay for a couple of seconds and guarantee that even if > > the Synchronise Cache command didn't work, the drive will still have > > flushed it's cache. Oops, looks like that's what I committed the other > > day. > > You're toying with me, aren't you? Not at all. Since we can't guarantee a flush-to-stable-storage for anything other than a subset of SCSI disks, the smart thing to do is to wait for some time that ought to be greater than the typical flush delay plus flush time between the last write we make and the time that we pull the plug. A little empirical testing has suggested that about 5 seconds works well here; this is enough to make most laptops power down cleanly as opposed to leaving their disks dirty. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message