From owner-freebsd-scsi Wed Oct 14 08:02:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03021 for freebsd-scsi-outgoing; Wed, 14 Oct 1998 08:02:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03010; Wed, 14 Oct 1998 08:02:15 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA05240; Wed, 14 Oct 1998 09:01:47 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA04936; Wed, 14 Oct 1998 09:01:46 -0600 Date: Wed, 14 Oct 1998 09:01:46 -0600 Message-Id: <199810141501.JAA04936@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Terry Lambert , Don.Lewis@tsc.tdk.com, julian@whistle.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810140518.XAA15040@pluto.plutotech.com> References: <199810140049.RAA20004@usr08.primenet.com> <199810140518.XAA15040@pluto.plutotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >If writes are committed in dependency order, and the write is cached > >and there is no reordering of subsequent writes (ie: writes occur in > >tag order, even if they are cached), then I think this satisifies soft > >updates. > > You have no guarantee that the writes will be committed to the media in the > order that they were reported as completed to the host if you use write > caching. You do have a guarantee, however, that the cache contents are > always consistent and if you allow the drive to flush it's cache, the > media will eventually be consistent as well. ... > This is why you must have a UPS. I thought we already went over this > before... Bottom line is that by default FreeBSD w/SoftUpdates is more *unstable* now with CAM than it was w/out CAM for 99% of the users. You can argue all day long that people have broken firmware, crappy power supplies, or sun spots, but the bottom line is that CAM is making it so people's file systems are hosed when they don't have to be. Architecturally it would be nice if everyone had a UPS, a great power supply that didn't 'spike' the power line, and perfect firmware but this isn't a perfect world. Far from it. We live in an imperfect world and that won't change just because CAM likes perfection. IMO, CAM should disable write caching by default, and allow people to add it back by hand if they know how. I don't know how this would be done, but it's *ALWAYS* a better idea to be safe than to be sorry. Never optimize when the optimizations are a pessisimization for most of the users. Nate ps. I have both good firmware and a appropriately configured UPS that correctly powers down the system, so don't be yelling at me for having bad hardware. But, I'm an exception to the norm, in many ways. :) :) :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message