Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 May 2006 10:30:29 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        "Eugene M. Kim" <freebsd.org@ab.ote.we.lv>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: dump(8) performance
Message-ID:  <20060531153029.GE6982@dan.emsphone.com>
In-Reply-To: <447DB0B1.8040206@ab.ote.we.lv>
References:  <447DB0B1.8040206@ab.ote.we.lv>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060531153029.GE6982>