On Sun, Nov 26, 2006 at 11:11:50PM -0500, Louis Guillaume wrote:
> Any idea what's going on here? Device and system info are below...

I've run into something similar, although without quite so abysmally low
rates.

most helical scan drives (DAT and DLT) don't do well if you can't keep
them streaming.  if they get underflows, they have to reposition the
tape to figure out where they left off.

rmt only has a single queue.  when transferring data, it reads from the
network, then writes to the tape device.  this maintains synchronism and
is the simplest safest model, but can perform poorly with simplistic rmt
clients like dump.

dump has only a single output queue.  combine this with rmt's
synchronism, and you get a half-duplex network operation.  there can be
no data in-flight or buffered on the network, since additional blocks of
data cannot be sent until the one in-flight has been written to the
device and ack'd to dump by rmt.  as latency and buffering go up,
performance goes down.

the whole dump -> rmt -> tape write interaction ends up going in fits
and starts.

schilly's tar (star, in pkgsrc/archivers/star) can be configured to
perform double buffered writes to rmt, and performs considerably better
due to it.  star also ships with its own rmt, but I did not seen any
performance benefits from using it.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
              "silly brewer, saaz are for pils!"  --  virt