From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 08:47:27 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 08E4616A4BF for ; Wed, 1 Oct 2003 08:47:27 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F7E543FB1 for ; Wed, 1 Oct 2003 08:47:26 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id MUA74016; Wed, 01 Oct 2003 08:47:24 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D35CD5D07; Wed, 1 Oct 2003 08:47:23 -0700 (PDT) To: Jens Rehsack In-Reply-To: Message from Jens Rehsack of "Wed, 01 Oct 2003 06:39:47 -0000." <3F7A76B3.6080508@liwing.de> Date: Wed, 01 Oct 2003 08:47:23 -0700 From: "Kevin Oberman" Message-Id: <20031001154723.D35CD5D07@ptavv.es.net> 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: Wed, 01 Oct 2003 15:47:27 -0000 > Date: Wed, 01 Oct 2003 06:39:47 +0000 > From: Jens Rehsack > > 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. Yes. This is fairly well known with many, many messages in the archives. If you want serious stability, you need to turn off the disk write cache. I have it off on my office system here and on on my laptop. But thanks for bringing this up as it is important. And, yes, it has burned me, although it required a confluence of things all going wrong at exactly the right timing to catch a bunch of metadata in cache. (This could only have happened on a CURRENT system back in the 5.0 time frame.) It could only happen when the file system had been very active with an installworld. But it did happen. The trade-off is a big performance hit. With disk cache on, I can copy my entire FreeBSD partition to another disk in about 15 minutes. With disk cache off, it took a few HOURS. This was a worst case example with dd on my laptop (slow disks). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634