>Indeed, but then you use 40 virtual tapes at once and we only have 100 
>virtual tapes online.  When the oldest cycles start to recycle, the
tape 
>can still be full for a long time if there is data written on it over a

>period of let's say 10 days.  If we maken smaller but more tapes, we 
>need a more expensive license to deal with an autochanger with that
many 
>slots.  And if we chose not to keep all the volumes online, and have 
>fewer slots, we need to manually change the tapes virtually with the
VTL 
>software as if we were changing the tape in a tape robot and storing 
>them in a vault.  That's a lot of overhead.

I agree.  EMC's not being very VTL-friendly with a slot-based pricing
model.  Pressure them to offer a capacity-based model as well, and then
you wouldn't have the issue you describe.

>is the dedupe an option?  We have the VTL from SUN, and if we read 
>from a VTL device with parallelism 4 for example, we read at a lot less

>of the max read speed (I don't think it is 1/4th like with a tape
device).

Again, there is no reason to multiplex to virtual tape drives.  Create
more virtual tape drives and turn off multiplexing.

As to your question, dedupe is an option on SOME VTLs.  I'm not sure if
Sun is reselling Falconstor's dedupe offering yet.

 

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER