From owner-freebsd-hackers@FreeBSD.ORG Wed May 31 15:30:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DE5316B5E7 for ; Wed, 31 May 2006 15:30:32 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8FB643D48 for ; Wed, 31 May 2006 15:30:31 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.4) id k4VFUTGn096724; Wed, 31 May 2006 10:30:29 -0500 (CDT) (envelope-from dan) Date: Wed, 31 May 2006 10:30:29 -0500 From: Dan Nelson To: "Eugene M. Kim" Message-ID: <20060531153029.GE6982@dan.emsphone.com> References: <447DB0B1.8040206@ab.ote.we.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <447DB0B1.8040206@ab.ote.we.lv> X-OS: FreeBSD 5.5-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: dump(8) performance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2006 15:30:37 -0000 In the last episode (May 31), Eugene M. Kim said: > While watching the output of iostat -dxz -w10 -n100 to monitor the > progress/performance of a dump(8) process straight to a tape, I found > out something interesting and disappointing at the same time: The > disk read throughput was exactly twice as high as the tape write > throughput, throughout the entire dump phases 4 and 5, i.e. dumping > actual inodes. Disappointing, because the tape drive utilization > (%busy) was lingering around 35%-50% for most of the time; I didn't > expect the disk would be the bottleneck. :p > > I want to believe that this indicates a bug in dump(8) which causes > each disk block to be read twice, but being no UFS expert in any > sense, I wonder: Could this behavior be by design, and would there be > any room for improvement? Are you using the -C option to dump? I would expact that to help more in the "dumping directories" step, but it might help later phases too. -- Dan Nelson dnelson@allantgroup.com