LTO4 drives will read, but not write LTO2 media. Kelly Lipp CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 x7105 www.storserver.com
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Howard Coles Sent: Thursday, March 19, 2009 1:52 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same library We do this with a mixed LTO3 and LTO2 drives. We did not partition the library. However, I would highly suggest putting the smaller format higher in the drive number list. DRIVE01 = LTO2 . . . DRIVE10 =LTO4. That will keep the LTO4 drives available for LTO4 tapes, if LTO4 drives will read and write LTO2 tapes. See Ya' Howard > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf > Of David McClelland > Sent: Thursday, March 19, 2009 9:13 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same > library > > Hi Team, > > I've a question about mixing LTO drives and media in the same library - > LTOn > and LTOn+2. > > * Windows TSM 5.4.3.2 (soon to be migrated to a 5.5.1.1 server running > on > AIX) > * IBM 3584 single frame library, presently with 4 x IBM LTO2 drives > * Currently no library clients or storage agents. > > My client is looking to migrate from 4 x LTO2 drives to 8 x LTO4 drives > in > their 3584 library (as well as performing some other TSM Server > platform > migration activities). > > The LTO drive generation-spanning capabilities are such that LTO4 > drives can > read from but not write to LTO2 media; that LTO2 drives can read/write > to > LTO2 media, but will have nothing to do with LTO4 media. > > Now, for an interim period, it has been suggested that the library be > configured with 5 x LTO4 drives and 3 x LTO2 drives. TSM Server and the > IBM > 3584 Tape Library are both stated to support mixed media and tape > drives > between these LTO generations. > > However, the idea behind this is that during this interim period, new > incoming backup data should be written to LTO4 media by the LTO4 drives > (as > well as some existing LTO2 data being moved/consolidated onto LTO4 > media), > and that offsite copies only continue to be generated to LTO2 media > using > the LTO2 drives (various reasons for this, including maintaining media > compatibility for DR purposes). If possible, largely I think for > flexibility, the preference is to achieve this within a single library > partition. > > It's this last bit that I'm having trouble getting my head around. > > Obviously, a new device class (FORMAT=ULTRIUM4C) will be added to the > TSM > Server to make use of the LTO4 drives (making sure that the current > LTO2 > device class is locked down to FORMAT=ULTRIUM2C), as will a new set of > LTO4 > storage pools pointing to this new device class. However, with both of > these > drive types being located in a single library partition I don't quite > see > how they'll be able to make sure that only LTO2 scratch tapes get > mounted > into LTO2 drives and that LTO4 drives don't go trying to write to LTO2 > media. Is it simply a case of manually allocating the LTO2 scratch > media to > the LTO2 copy storagepool (and setting its MAXSCRATCH to 0), and > ensuring > that LTO4 is the only media in the general scratch pool? Will TSM > ensure > that, given we're explicit in our device class definitions, when a > backup > stgpool operation requests a mount of an LTO2 scratch volume (or indeed > an > LTO2 filling volume) to perform a write it'll only mount one into one > of the > LTO2 drives, and similar for LTO4 media and drives? I suspect not... > > Is anyone running with a similar configuration to this (if it's > possible)? > > Of course, the other blindingly obvious option is to partition the > 3584, > creating one library partition for the 3 x LTO2 drives and enough slots > to > manage the offsite requirement, and another for the 5 x LTO4 drives > with the > remainder of the carts. The client doesn't have ALMS for quick flexible > library partitioning (I don't know about the cost of this feature, but > I > expect that they'd be unwilling to consider it for only an interim > period) > so we'd have to use more rigid non-ALMS partitioning method. This > option > appeals to me in that it's pretty simple to get my head around, but > perhaps > requires a little more work to perform the library repartitioning. > > Any thoughts gratefully received! > > Cheers, > > David Mc, > London, UK > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.11.18/2009 - Release Date: > 18/03/2009 > 07:17 >
