From owner-freebsd-fs Sun Oct 18 12:25:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26817 for freebsd-fs-outgoing; Sun, 18 Oct 1998 12:25:32 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26811; Sun, 18 Oct 1998 12:25:29 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA24141; Sun, 18 Oct 1998 12:25:05 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd024134; Sun Oct 18 12:24:59 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA19638; Sun, 18 Oct 1998 12:24:58 -0700 (MST) From: Terry Lambert Message-Id: <199810181924.MAA19638@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sun, 18 Oct 1998 19:24:58 +0000 (GMT) Cc: tlambert@primenet.com, dkelly@hiwaay.net, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810162349.RAA11679@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 16, 98 05:42:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >The errors seen are a result of uncommitted data in the drive cache, > >not power spikes and gremlins. The interaction is well understood, > >and on firm footing unrelated to Stephan King novels. > > And why do you think the drive didn't bother to commit the data even > though power was constantly supplied to the drive and only a few, > recent transactions were lost? Most likely because hitting the > reset switch caused a power glitch that reverted the drive to its > power on state. I think it's because the PCI bus POSTed the controller, resulting in a SCSI reset, which lost the uncommitted data. It's a lot easier to believe that than to believe the other. I suppose we should test by making a loadable system call that directly calls the reset code, so as to put the "reset causes a reset reliably, but even though no hardware other than the disk write cache is affected, we believe it's because no one debounced the switch" theory to rest. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message