Date: Fri, 02 Oct 1998 10:39:50 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching Message-ID: <199810021646.KAA21621@pluto.plutotech.com> In-Reply-To: Your message of "Fri, 02 Oct 1998 02:52:34 PDT." <199810020952.CAA15297@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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. This is a non-conclusive result. By disabling the cache, you have effectively reduced the concurrent transaction count which may mask bugs elsewhere in the system. So long as you do not lose power to your SCSI disk (which the reset button should not cause to occur), the cache should have no impact on the results of your test. >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. In this particular benchmark, perhaps not, but make buildworld is not indicative of most I/O loads. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810021646.KAA21621>