Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Oct 1998 11:59:26 -0700 (PDT)
From:      Julian Elischer <julian@whistle.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:  <Pine.BSF.3.95.981002115603.15828A-100000@current1.whistle.com>
In-Reply-To: <199810020952.CAA15297@salsa.gv.tsc.tdk.com>

next in thread | previous in thread | raw e-mail | index | archive | help
you are correct.

write caching can screw soft updates if there is any
major re-ordering of the data written.

With tags it doesn't matter if they are re-ordered, as long
as they are not acknowledged until they are on the platter.

As you noted, softupdates itself does reduce the value of 
drive write caching, and in fact I'm glad that your numbers agree
with my expectations.

julian


On Fri, 2 Oct 1998, 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.
> 
> 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.
> 
> 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.
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
> 


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?Pine.BSF.3.95.981002115603.15828A-100000>