The original 3480 cartridge only held 500MB. The high-end 6250 rounds held about a fifth. How time can easily skew our numbers.
-----Original Message----- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 11:44 AM To: [EMAIL PROTECTED] Subject: Re: TSM and VTS - virtual volumes Zlatko, The design of the VTS was to allow a bunch of (relatively) small files to be written to the VTS cache (a bunch of disk) as "virtual" volumes, then "stacked" together on one of the new big tapes. Consider if you had a lot of old round tapes; they only held about 200 MB. And in most people's tape libraries, all the tapes aren't full, anyway, so each tape represents considerably less than 200 MB. If you try to convert these round tapes to 3590 tapes (which these days can hold 40 GB, before compression), you waste a LOT of expensive 3590 tapes. If you take the round tapes and move them into the VTS, they go into the disk cache as "virtual" volumes, then migrate out to the 3590 tapes "stacked" together so you make good use of the 3590 tapes. Now TSM does not put each file it backs up on a tape as a separate file. It glops them altogether in one BIG FILE file that grows until it fills the entire tape. If you send the TSM tapes to a VTS, it writes until the "virtual" volume is full. The max size of a "virtual" volume is set by the person who configures the VTS. Let's assume for argument that you set the max virtual volume size to 2 GB. So in a VTS, TSM writes backup data into one big file that can grow to 2 GB. That usually works pretty well for people during backups. Virtual volumes go out to the VTS cache (disk pool), and then migrate out to a 3590 tape. The trick is that the entire 2 GB "virtual volume" migrates as a unit. The performance problem usually hits when you want to do a restore. You may want to restore one TSM file that is only 1 MB; but when you tell TSM to do the restore, it tries to "mount" the virtual volume, which means it has to go to the 3590 tape, and destage the WHOLE 2 GB "virtual volume" back to the disk cache before it can start reading. So (1) the destaging of the whole 2 GB virtual volume takes time, and (2) it "pollutes", or uses up, your disk cache, which then affects performance for the next request. Consider what a problem that can cause, if you try to create your COPY POOL tapes AFTER the "virtual volumes" have migrated out to the 3590's - EACH VOLUME has to be "destaged" back to the disk cache before it can be read by TSM. That causes a whole lot of thrashing and slows things down. So the design of a VTS is optimal for SMALL files on tape, not for applications like TSM or DFHSM that, by design, write to tape until a whole tape is full. The VTS can still work nicely for TSM, IF you have a lot of disk cache space (the bigger the cache in the VTS, the more it costs), and IF you have a low level of destaging activity. Hope that helps.. ************************************************************************ Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 9:53 AM To: [EMAIL PROTECTED] Subject: Re: TSM and VTS - virtual volumes If VTS is artifically configured TSM server backend this leads to another question - virtual volumes performance. We read recently on the list that TSM using VTS is having not so good performance. Is this true or not I cannot prove and cannot have clear opinion. But virtual volumes are by definition TSM server backing up to TSM server. And if TSM-TSM performance is good why not TSM-VTS (i.e. TSM) performance be good? And how we can define "good" or "better" or "average"? If TSM-VTS is performing "not so good" is TSM-TSM having similar performance (measured in GB/hour or something similar)? If both perform at comparable speeds can we say both are "not so good" or TSM-TSM performs better? Sorry for asking so many questions. I have no mainframe (and VTS) to answer them by myself. Zlatko Krastev IT Consultant Michael Bartl <[EMAIL PROTECTED]> on 03.12.2001 10:48:11 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: TSM and VTS I remember from an IBM presentation a few years ago that the technology behind VTS is TSM. So using a VTS library on a TSM server means stacking the same intelligent tape management technology for two instances. This can eliminate some of the benefits. On one hand, when collocation is "inactivated" by VTS, access performance to your data may drop. On the other hand, VTS uses quite a lot of disk caching to improve performance. It depends on the structure of a TSM servers data, whether the gain or loss in performance will be stronger. Best regards, Michael -- Michael Bartl mailto:[EMAIL PROTECTED] Office of Technology, IT Germany/Austria Tel: +49-89-92699-806 Cable & Wireless Deutschland GmbH. Fax: +49-89-92699-302 Landsberger Str. 155, D-80687 Muenchen http://www.cw.com/de Bill Mansfield wrote: > > The fact is that TSM does not always write tapes 'til they are full. If > you have a bunch of small nodes using collocation or backupsets, you can > wind up with a lot of expensive tape with little content. Using the VTS > would allow you to stack these nearly empty tapes onto one tape. I'm not > sure whether this defeats the purpose of collocation, since I'm not sure > that the virtual tapes will stay collocated inside the VTS, though. > > _____________________________ > William Mansfield > Senior Consultant > Solution Technology, Inc >
