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. Greg -- See complete headers for address and phone numbers.
pgpbFLHhXJTNg.pgp
Description: PGP signature
