-----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 4:36 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Multiplexing on VTL's

> Good reason #1:  in my VTL testing experience, making a boatload of
> drives from the VTL's available disk space leads (of course) to fewer or
> smaller tapes.  And a backup that requires a dozen tapes because they're
> only 10GB-sized incurs a significant time penalty from all those media
> change times.

===
Speaking only for my NetApp VTLs here, but the 'media change time' as in 
'rewind, unload drive, put tape in slot, grab a new tape from slot, put in 
drive, mount/position' takes next to no time at all. Fractions of a second.
===

> Good reason #2:  backing the number of drives down produced a need to
> multiplex in order to have N jobs in execution (the reason for all those
> virtual drives in the first place--throw a drive at every job required).
> Multiplexing worked fine.  In non-real-world mux testing (simultaneous
> backups of the same directories on a media server), aggregate throughput
> improved all the way up to mux 32.

===
Multiplexing WILL work. In my ever so humble opinion, MPX was a band-aid to 
address the 'how to pipe data fast enough to fast tape drives' question. The 
VTL doesn't care. 1 MB/s or 100MB/s or anything in-between is fine.
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.
A VTL without MPX _may_ be more effective at doing restores.
===

> Good reason #3:  the administrative overhead of, say, 128 drives versus
> 16 quickly became annoying.  Pages and pages of tpconfig listings going
> off the screen, or GUI device monitor to look through... hard to see the
> drive situation at a glance... process-troubleshooting... it slows
> things up in real and (probably) imagined ways.

===
While true, my experience is that virtual drives are quite reliable. There's no 
write errors or read errors detected by the media servers, and they don't have 
reasons to DOWN their drives. (That's somewhat of a simplification... if there 
are SAN hiccups, media servers may down all their drives immediately...)
===

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