On Wed, 2006-May-31 08: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.
I looked into dump performance many years ago (as part of a thread which resulted in Matt Dillon adding the existing caching code) but can't find my notes right now. From memory, the main problems were that dump would re-read the inode multiple times and the physical read sizes were (pretty much) limited to the filesystem blocksize. The caching code increases the read blocksize but this also means that data read from the disk may not be needed. Dumping small files is the worst case. If you remove the '-C' parameter, you'll probably find that your disk throughput drops to only slightly more than the tape throughput, though the tape utilisation will probably drop further. If your concern is tape drive utilisation (because you want it for other tasks) or the tape drive dropping out of streaming mode, your only real solution is staging to disk. I wrote a tool similar to ports/misc/buffer that supported hysteresis to minimise the number of start/stop cycles but it only marginally speeds up the total dump time (sometimes dump runs faster than the tape and so a buffer helps here). There probably is more scope for enhancing dump throughput. -- Peter Jeremy _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
