From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 10:03:54 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 22C7116A4BF for ; Thu, 2 Oct 2003 10:03:54 -0700 (PDT) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5BAB43FF5 for ; Thu, 2 Oct 2003 10:03:52 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfi2e.dialup.mindspring.com ([165.247.200.78] helo=mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A56rf-0002vZ-00; Thu, 02 Oct 2003 10:03:44 -0700 Message-ID: <3F7C5A33.A13BC11C@mindspring.com> Date: Thu, 02 Oct 2003 10:02:43 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jens Rehsack References: <20030930221148.54E7E5D07@ptavv.es.net> <3F7A76B3.6080508@liwing.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f42ba7020b7cab26f3c9b74c04b76bd5387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c 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: Thu, 02 Oct 2003 17:03:54 -0000 Jens Rehsack wrote: > Kevin Oberman wrote: > > Current has two major changes re speeding up fsck. > > > > The most significant is the background operation of fsck on file > > system with soft updates enabled. Because of the way softupdates > > works, you are assured of metadata consistency on reboot, so the file > > systems can be mounted and used immediately with fsck started up in > > the background about a minute after the system comes up. > > Be careful what you promise :-) > Most new disks have an own disk cache and some of them have a > write cache enabled. In case of a hardware failure (or power > failure) this data may get lost and the disk's metadata isn't > consistent. It's only when no write cache below the system > is active. 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. -- Terry