From owner-freebsd-hackers@FreeBSD.ORG Wed May 31 23:51:05 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 B27E416CC11 for ; Wed, 31 May 2006 23:48:39 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ext-gw.lemis.com (ext-gw.lemis.com [150.101.14.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C871943D5E for ; Wed, 31 May 2006 23:48:36 +0000 (GMT) (envelope-from grog@lemis.com) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.135]) by ext-gw.lemis.com (Postfix) with ESMTP id B39D2131E13; Thu, 1 Jun 2006 09:18:35 +0930 (CST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 9275286F5A; Thu, 1 Jun 2006 09:18:35 +0930 (CST) Date: Thu, 1 Jun 2006 09:18:35 +0930 From: Greg 'groggy' Lehey To: "Eugene M. Kim" Message-ID: <20060531234835.GW54613@wantadilla.lemis.com> References: <447DB0B1.8040206@ab.ote.we.lv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Wosya/OiUJZ+2ov" Content-Disposition: inline In-Reply-To: <447DB0B1.8040206@ab.ote.we.lv> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 VoIP: sip:0871270137@sip.internode.on.net WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 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 23:51:18 -0000 --9Wosya/OiUJZ+2ov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 31 May 2006 at 8:05:21 -0700, Eugene M. Kim wrote: > 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? Without looking at the code, this seems unlikely. But you might get more information by attaching a ktrace to the dump process for a short period of time (find the pid, then ktrace -p to start trace, ktrace -p -C to stop again). If you do that, let me see no more than 30 lines of repetitive trace. Greg -- See complete headers for address and phone numbers. --9Wosya/OiUJZ+2ov Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFEfitTIubykFB6QiMRAnhAAKCMKBfWpWMhn4wrYSGz6aEK+VcU5gCfQSiY FPDtd80GvrsdOtfkwunSvn0= =r0mD -----END PGP SIGNATURE----- --9Wosya/OiUJZ+2ov--