Hello Bob

I agree with b and c, but there a can be a little misleading as we learned the 
hard way this past year.
Netbackup records the start of a fragment and not the location of the file on 
the tape. So it has to read the whole fragment until it finds the file it is 
looking for.

len

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of bob944
Sent: Wednesday, April 30, 2008 9:03 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Multiplexing on VTL's


> My main concern is that when doing restores off a multiplexed
> tape, the VTL READ speed off the disk(let's say it's 80MB/s)
> is the same whether there's MPX in the stream or not. The
> restore will throw away the bytes that doesn't belong to the
> client, so out of a 80 MB/s stream coming off the disk, you
> will throw away (let's say) 60MB and use only 20. It's this
> reduction in effective restore speed that's my main concern.

Perhaps you'll have time to test and share here?  I'd expect NetBackup
to treat it as multiplexed tape and not read the intervening data.  IME,
most multiplexed-tape-restore horror stories are no longer valid due to
a) fast-locate-block's ability to skip the intervening data (I have
never explicitly tested this), b) drives that supply data faster than
the client can write it and c) properly designed multiplexed backups can
restore multiple clients significantly faster than non-muxed (I have
tested b and c).


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu