From owner-freebsd-fs Fri Oct 2 06:26:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24761 for freebsd-fs-outgoing; Fri, 2 Oct 1998 06:26:56 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA24732; Fri, 2 Oct 1998 06:26:39 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA12369 (5.67b/IDA-1.5); Fri, 2 Oct 1998 14:59:34 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id OAA29167; Fri, 2 Oct 1998 14:06:50 +0200 (CEST) From: Wilko Bulte Message-Id: <199810021206.OAA29167@yedi.iaf.nl> Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810020952.CAA15297@salsa.gv.tsc.tdk.com> from Don Lewis at "Oct 2, 98 02:52:34 am" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Fri, 2 Oct 1998 14:06:50 +0200 (CEST) Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] 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 As Don Lewis wrote... > > I was doing some torture testing of softupdates, CAM, and fsck by > hitting the reset button on a running system and noticed that fsck > would sometimes encounter inconsistencies in the filesystem that > should not be happening, such as directory entries that pointed to > unallocated inodes. I tracked the problem down to write caching > being enabled on the machine's SCSI disk. After using camcontrol to > disable write caching, this problem went away. Yuck. Write caching on disks is evil. I've discussed this kind of thing at great length with the disk gurus at work. There is consensus: write caching is not to be trusted, there are even firmware incarnations out there that get confused by a SCSI bus reset and loose track of what they have cached. Admittedly this is junk firmware, but it seems to happen. This is the kind of stuff that makes the Oracle-s of this world extremely nervous ;-) > It would be nice if folks in this situation would get a warning that > their filesystems could get trashed because the disk has write caching > enabled. I think the best situation would be to issue this warning at > filesystem mount time (though folks who use async mounts shouldn't get > an extra warning about write caching, their filesystems may get trashed > anyway). This would require a communications channel between the > filesystem and CAM. Another possibility would be to just issue a > brief warning when the device is probed at boot time. Even a warning > in the documentation would be helpful, at least for those who bothered > to read it. You'd have to dig into the modepages of the drives. Makes for a somewhat kludgy interface in the SCSI subsystem all the way up to 'mount'. I'd rather put it into the device probe section for the da devices. > BTW, with softupdates, and tagged command queuing enabled in CAM, there > is not much of a performance hit from turning off write caching. I > saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, > and "make -j6 buildworld" increase from about 1 hour 30 minutes to > 1 hour 35 minutes. Negligible difference in my book. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message