From owner-freebsd-fs Fri Oct 2 09:46:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA27222 for freebsd-fs-outgoing; Fri, 2 Oct 1998 09:46:52 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA27200; Fri, 2 Oct 1998 09:46:40 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA21621; Fri, 2 Oct 1998 10:46:20 -0600 (MDT) Message-Id: <199810021646.KAA21621@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 02 Oct 1998 02:52:34 PDT." <199810020952.CAA15297@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Oct 1998 10:39:50 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >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