From owner-freebsd-scsi@FreeBSD.ORG Wed Dec 10 12:08:19 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DD0316A4CE for ; Wed, 10 Dec 2003 12:08:19 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 974F443D30 for ; Wed, 10 Dec 2003 12:08:17 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hBAK84eF053469; Wed, 10 Dec 2003 12:08:09 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200312102008.hBAK84eF053469@gw.catspoiler.org> Date: Wed, 10 Dec 2003 12:08:03 -0800 (PST) From: Don Lewis To: ict@cardinalnewman.coventry.sch.uk In-Reply-To: <200312101621.40138.ict@cardinalnewman.coventry.sch.uk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-scsi@FreeBSD.org Subject: Re: More Adaptec 29320 + Seagate ST336607LW woes X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 20:08:19 -0000 On 10 Dec, ict technician wrote: > On Saturday 06 December 2003 7:29 pm, Don Lewis wrote: >> On 6 Dec, ian j hart wrote: >> > On Friday 05 December 2003 8:33 pm, Don Lewis wrote: >> >> I've been meaning to suggest that if you haven't done so already, use >> >> "camcontrol modepage" to set the WCE bit to 0 which will disable write >> >> caching on the drive. In the testing that I've done, I haven't seen any >> >> significant performance penalty in doing this if tagged command queuing >> >> and softupdates are in use. It is also safer for soft updates because >> >> the drive no longer lies about when write data reaches stable storage. > > I'll add it to my "things to try" list. Don't want to compromise the data I'm > collecting tho'. ie it's a new variable to the equasion. > > A deep tagged commands queue would be a bit like a cache, wouldn't it? I > suspect you would see a significant performance decrease if you also reduced > the queue depth. It probably depends a lot on the characteristics of the I/O load. The drive may be able to more optimistically schedule the physical I/O if it has a bigger queue to work with. For example, if reads or writes to nearby sectors are separated by many commands, a larger queue depth may allow the drive to see both commands and cluster the physical I/O, whereas it would not be able to do this if both commands were not in the queue at the same time. > What happens to the queue when I press the power switch? Any queued writes are lost, along with the soft updates work queue, and a sector being written at the time might be corrupted. Other than the bad sector, the file system will be in a consistent state and fsck should be able to repair it. The data lost in the disk queue will also still be in the soft updates work queue, so it is essentially the last N seconds of file writes. The file system may well not be left in a consistent state after a power loss if WCE is on, which means that fsck may not be able to do an automatic repair and may require manual intervention. The data for any file is guaranteed to be on the platter after an fsync() if WCE is off, but not if it is on. The latter means that if you use fsync() a lot, you'll see a performance hit.