How does one configure the blocksize?
What about the blocksize used on the tape? perhaps that can be tuned, too...
g.
> -----Original Message-----
> From: Marc W. Mengel [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 30 January 2001 3:12 AM
> To: [EMAIL PROTECTED]
> Cc: Grant Beattie; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: why | ufsrestore?
>
>
>
>
> 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
>
>
>
