| 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.

  Exactly, that is one of the bottlenecks. Following Manuel's mail,
I invested a bit of time in adding a caching layer to dump's bread(),
so full 32k blocks are read at a time.

  This got a visible speed improvement most of the time. However,
Manuel cued me that because dump spawns multiple processes for its
reading, the cache might not be as effective -- and indeed, my traces
showed that blocks were read at least three times (default setting
of SLAVES).

  So I modified the cache to share data between all processes, and
this gave another performance boost (see below for empiric data).

  Normal 1.3.3 dump:

| % /sbin/dump 0sbf 888888 128 /dev/null /home
|   DUMP: estimated 1700904 tape blocks on 0.10 tape(s).
|   DUMP: Volume 1 transfer rate: 1509 KB/s

  With separate cache:

| % ./dump 0sbf 888888 128 /dev/null /home
|   DUMP: estimated 1700903 tape blocks on 0.10 tape(s).
|   DUMP: Average transfer rate: 2220 KB/s

  With shared cache:

| % ./dump 0sbf 888888 128 /dev/null /home
|   DUMP: estimated 1700923 tape blocks on 0.10 tape(s).
|   DUMP: Average transfer rate: 2748 KB/s


  The cache routines need some cleanup and some tuning, but for an
interim solution it's not so bad...

	mjl