dump(8) performance

Eugene M. Kim freebsd.org at ab.ote.we.lv
Wed May 31 08:05:15 PDT 2006

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?


More information about the freebsd-hackers mailing list