growisofs performance measurements
Hi!
Andy Polyakov asked me to share my experiences with some performance
measurements I have done using growisofs.
When I was backing up a large number of files using growisofs, I ran into
a case where performance was lower than expected. I was backing up a large
directory tree to a DVD+R disc, writing at 4X speed. The directory tree
contained approximately 193000 files and the resulting ISO image was
3517MB. In the first attempt I let growisofs run mkisofs automatically,
like this:
growisofs -r -J testdir/ -speed=4 /dev/scd1
The operation took approximately 1260 seconds and I observed that the
writing speed was much lower than 4X most of the time (1-2x was not
uncommon). The interesting thing was that the hard disk wasn't working
fully even when the writing speed was significantly lower than 4x. (The
hard disk light was off for up to 0.5s at a time.)
It turned out that this was caused by the fact that growisofs communicates
with the mkisofs program using a standard unix pipe, and on linux the pipe
buffer is only 4KB big. This means that when growisofs is busy sending
data to the DVD writer, mkisofs can not write more than 4KB to the pipe
before it gets stuck. Therefore, mkisofs and growisofs didn't work very
much in parallel.
I wrote a simple pipe buffering program and repeated the test like this:
mkisofs -r -J testdir/ | pipebuf2 -b 32 |
growisofs -speed=4 -Z /dev/scd1=/dev/fd/0
The pipebuf2 program implements a simple ring buffer with a size (in MB)
specified by the -b switch. This means that in the example above, mkisofs
can get up to 32MB ahead of growisofs without being stalled. The same test
case now took 943s, a 25% improvement.
I tried the same test case again with a 256MB buffer and this time the
operation took 870s, which is pretty close to optimal for this test,
because sending the same mkisofs data directly to /dev/null took 864s.
How much time this buffering gains depends a lot on the data you are
burning. If almost all files are quite large, mkisofs can usually keep up
without extra buffering. (The buffer in the DVD writer ensures that short
stalls in the data stream from mkisofs don't reduce performance.) On the
other hand, if all files are very small, mkisofs might not be able to ever
get ahead of growisofs, so the pipe buffer will never fill up. The extra
buffering will give the largest performance enhancement if you are burning
a mix of small and large files.
The pipebuf2 program is GPLed and can be downloaded here:
http://w1.894.telia.com/~u89404340/pipebuf2.c
(The program is called pipebuf2 because there already exists a program
called pipebuf that does pretty much the same thing, except that it uses
SysV IPC shared memory, which makes it impossible to use very large
buffers.)
--
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340
Reply to: