>
>Hi,
>I am the only one to find that dump is slow ?

Nope.

>Only 774 KB/s dumping to /dev/null a disk that can do 10Mb/s read/write
>throuh the filesystem.
>Changing SLAVES from 3 to 1 in tape.c increase dump speed from 40 to 100%
>on the disk I've tested (1056 KB/s for the disk above, ~400KB/s to more than
>800KB/s on an older IDE disk). My guess is that accesses are more sequencial
>with only one slave. 1056 KB/s is still not enouth for my DLT7000.
>
>Does someone have ideas about how to increase dump's performances ?
>I'll try to add some king of cache/read ahead technique to bread() and see
>if it helps.

Pluto had John Polstra do some analysis of dump a while back.  It turns out
that by having dump always do 32-64K reads and LRU'ing 20 or so blocks, you
can vastly increase dumps performance.  Since you must serialize the output
yet still have multiple readers filling the cache at a time (think tagged
queuing) there are some cache resource deadlock issues and synchronization
work to be thought through too.  To complete the picture, John plans to
stream the protocol so that the multiple passes can be performed in
parallel (as work becomes available for the next stage, the next stage
services it) similar to CVSup, but not written in M3. 8-)  Pluto intends to
contract him in April for this work, but I cannot guarantee that the
funding will become available as things are tight here.  Should it happen,
the work will be released under a standard BSD license.

--
Justin