dump(8) performance

Greg 'groggy' Lehey grog at FreeBSD.org
Wed May 31 16:51:18 PDT 2006

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<pid> to start trace,
ktrace -p<pid> -C to stop again).  If you do that, let me see no more
than 30 lines of repetitive trace.

See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20060531/aa4f5bbd/attachment.pgp

More information about the freebsd-hackers mailing list