From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 09:36:02 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8D8D16A4B3 for ; Fri, 3 Oct 2003 09:36:02 -0700 (PDT) Received: from mail.liwing.de (mail.liwing.de [213.70.188.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id F30C543FAF for ; Fri, 3 Oct 2003 09:36:00 -0700 (PDT) (envelope-from rehsack@liwing.de) Received: (qmail 36725 invoked from network); 3 Oct 2003 16:35:57 -0000 Received: from stingray.liwing.de (HELO liwing.de) ([213.70.188.164]) (envelope-sender ) by mail.liwing.de (qmail-ldap-1.03) with SMTP for ; 3 Oct 2003 16:35:57 -0000 Message-ID: <3F7DA56D.8070002@liwing.de> Date: Fri, 03 Oct 2003 16:35:57 +0000 From: Jens Rehsack User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030928 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Don Lewis References: <200310022051.h92Kp6N1039873@gw.catspoiler.org> In-Reply-To: <200310022051.h92Kp6N1039873@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org Subject: Re: Improvements to fsck performance in -current ...? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2003 16:36:02 -0000 Don Lewis wrote: > On 2 Oct, Terry Lambert wrote: [...] >>Actually, write caching is not so much the problem, as the disk >>reporting that the write has completed before the contents of >>the transaction saved in the write cache have actually been >>committed to stable storage. >> >>Unfortunately, IDE disks do not permit disconnected writes, due >>to a bug in the original IDE implementation, which has been >>carried forward for [insert no good reason here]. >> >>Therefore IDE disks almost universally lie to the driver any >>time write caching is enabled on an IDE drive. >> >>In most cases, if you use SCSI, the problem will go away. > > > Nope, they "lie" as well unless you turn of the WCE bit. Fortunately > with tagged command queuing there is very little performance penalty for > doing this in most cases. The main exception to this is when you run > newfs which talks to the raw partition and only has one command > outstanding at a time. > > Back in the days when our SCSI implementation would spam the console > whenever it reduced the number of tagged openings because the drive > indicated that its queue was full, I'd see the number of tagged openings > stay at 63 if write caching was disabled, but the number would drop > significantly under load (50%?) if write caching was enabled. I always > suspected that the drive's cache was full of data for write commands > that it had indicated to the host as being complete even though the data > hadn't been written to stable storage. > > Unfortunately SCSI drives all seem to ship with the WCE bit set, > probably for "benchmarking" reasons, so I always have to remember to > turn this bit off whenever I install a new drive. A message from this morning ('file system (UFS2) consistancy after -current crash?') to this list describes exactly the situation on my fileserver a few month ago, except my machine runs with FreeBSD 4-STABLE and has an ICP-Vortex 6528RD controller. I think, disk's or controllers (short hardware) write cache is a problem. Maybe it shouldn't be in theory, but it is in real world :-) Best regards, Jens