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 [EMAIL PROTECTED] _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"