From owner-cvs-all Tue Dec 7 23:30:55 1999 Delivered-To: cvs-all@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id F27FD14D12; Tue, 7 Dec 1999 23:30:51 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id XAA24639; Tue, 7 Dec 1999 23:32:14 -0800 Date: Tue, 7 Dec 1999 23:32:14 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_shutdown.c In-Reply-To: <199912080726.XAA04037@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. > > > (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? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message