On Sun, 28 Jan 2001, John R. Jackson wrote:
>
> But you're comparing apples and oranges. As you've noted, going from
> disk to tape on the same machine gets 3 MBytes/s whether you are using
> ufsdump or Amanda is using taper to copy a holding disk image.
>
> But that's not what happens when Amanda is dumping a client direct to
> tape. The data has to go across the network (even if it's all on the
> local machine it still goes through the kernel network stack). And,
> probably even more important, Amanda does compression when dumping,
> not when writing to tape.
>
> So a dump to holding disk would be "slow" but the corresponding holding
> disk to tape operation would be "fast". But a direct to tape backup
> would pay the penalty and show the speed loss due to compression even
> though the tape I/O portion is going as fast as it is given data.
>
> You didn't mention what kind of dump rates Amanda reports. Those should
> more or less match your direct to tape numbers for large enough images
> to get a good sample and with similar clients.
>
> Note that I'm not saying something isn't wrong in Amanda. Just that
> we need to narrow down the list of culprits.
We've gotten excellent results here with cranking up the blocksize
of writes to the network in our old backup scripts (which always go
direct to tape). Everywhere except OSF1, which seems to get confused...
Marc
