-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bob944 Sent: Wednesday, April 30, 2008 4:36 PM To: [email protected] 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 - [email protected] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
