From owner-freebsd-hackers@FreeBSD.ORG  Wed May 31 15:05:12 2006
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
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 A7A3F16AC6F
	for <freebsd-hackers@freebsd.org>; Wed, 31 May 2006 15:05:12 +0000 (UTC)
	(envelope-from freebsd.org@ab.ote.we.lv)
Received: from purple.the-7.net (purple.the-7.net [207.158.28.23])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A049A43D46
	for <freebsd-hackers@freebsd.org>; Wed, 31 May 2006 15:05:08 +0000 (GMT)
	(envelope-from freebsd.org@ab.ote.we.lv)
Received: from [10.0.0.11] ([10.0.0.11])
	by purple.the-7.net (8.13.6/8.13.6) with ESMTP id k4VF57Kh029385
	for <freebsd-hackers@freebsd.org>; Wed, 31 May 2006 08:05:07 -0700 (PDT)
	(envelope-from freebsd.org@ab.ote.we.lv)
Authentication-Results: purple.the-7.net from=freebsd.org@ab.ote.we.lv;
	sender-id=neutral; spf=neutral
Message-ID: <447DB0B1.8040206@ab.ote.we.lv>
Date: Wed, 31 May 2006 08:05:21 -0700
From: "Eugene M. Kim" <freebsd.org@ab.ote.we.lv>
User-Agent: Thunderbird 1.5.0.2 (X11/20060516)
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: dump(8) performance
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2006 15:05:15 -0000

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?

Puzzled,
Eugene