Date: Fri, 2 Oct 1998 14:06:50 +0200 (CEST) From: Wilko Bulte <wilko@yedi.iaf.nl> To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <199810021206.OAA29167@yedi.iaf.nl> In-Reply-To: <199810020952.CAA15297@salsa.gv.tsc.tdk.com> from Don Lewis at "Oct 2, 98 02:52:34 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810021206.OAA29167>