The bug is IT02929; for us it affects Exports as well as restores (so I'm guessing would affect backupsets as well). And yes, hits any copypool, LTO or not.
OTOH, it's not necessarily hard to live with, depending on your situation. More details of that below. What you get with 7.1.1 that may make IT02929 worth living with for you: - much more function in the OC - ability to make the active log larger than 128G (important for people doing dedup) - migration from DISK pools occurs at filespace level instead of node level (fixes a pain point for people using VE, or other PROXY relationships) My experience with IT02929: It can hit you if 1) the data you are trying to restore or export is on both a primary and copypool volume 2) the copypool volume is marked reado or readw So if your copypool is tape, and you vault your copypool daily (so your copypool volumes are generally marked OFFSITE), you are unlikely to ever see the problem. We found it's easy to circumvent; before we do an export or if we see the problem occurring during a restore we do: update vol * wherestgpool=copypoolname whereaccess=readw access=unavailable When we are done with exports, we reverse it with: update vol * wherestgpool=copypoolname whereaccess=unavailable access=readw So for us it is quite manageable, as we don't do that many restores. Your circumstances may differ. Wanda Prather TSM Consultant ICF International Enterprise and Cybersecurity Systems Division -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Friday, January 30, 2015 10:02 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM rant The 7.1.1.100 server code has a rather serious bug affecting restores. If copy storage pool volumes are available the TSM server will mount both primary pool volumes and copy pool volumes when performing a restore. This is expected to be fixed in 7.1.1.200. The last time I checked, the target date for 7.1.1.200 was second quarter of 2015. That pretty much rules out a 6.2 to 7.1 upgrade, unless you are prepared to live with the bug described above. We are currently at 6.2.5.0, and expect to upgrade to 6.3.5.0 or 6.3.5.100. Thomas Denier, Thomas Jefferson University -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Friday, January 30, 2015 8:39 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM rant We just completed our conversion from v5 to v6.2.5 the end of December. In general we're very happy with v6.2.5, but then we don't use any of the newer features like dedup - and don't plan to. (we have DataDomain for our dedup load) V6 has really solved our v5 pain points: very long expirations (+24hr) and very slow db processing. We run a "morning report" every morning against our TSM servers. It generates a lot of info about an instance that we keep for documentation/reporting. Some of our "morning reports" ran over an hour due to heavy SQL cmds. Now on V6 the morning report runs in a few minutes! V6 has definitely raised the scalability of TSM. Yes, I have a long list of complaints about TSM, but in general we are happy with V6. Now that we are completely on V6.2.5, we have to upgrade quickly due to ending support in April. Our debate is going to v6.3.x or jumping to 7.1.x. I'd be interested in any recommendations for this. Thanks Rick PS: Just in case you are curious, here are the reports we generate in our "morning report": print "= r000 report index and beginning time stamp " print "= r010 activity summary " print "= r011 admin schedule activity " print "= r015 scratch count " print "= r019 scratch tape usage " print "= r020 tape vol summary for all TSM instances" print "= r021 reclaimable tapes by pct-reclaim " print "= r022 volume info " print "= r023 volumes per stgpool status and maxscratch " print "= r024 volume average utilization by stgpool " print "= r025 q dr " print "= r030 q path (not emailed)" print "= r036 drive activity " print "= r040 q db" print "= r045 q log" print "= r050 log consumption and utilization" print "= r055 log pin info (not emailed)" print "= r065 q sess" print "= r070 q stgpool" print "= r075 q copygroup (not emailed)" print "= r076 q events for exceptions - missed backups (not emailed)" print "= r077 slow backups" print "= r080 db backups" print "= r085 expiration - completions " print "= r090 expiration - detail (not emailed)" print "= r095 drive and media errors" print "= r097 nodes with tcp_ip or tcp_name changes" print "= r100 recplan dir listings" print "= r105 q volhost type=dbb" print "= r110 q volhost type=dbs (not emailed)" print "= r120 stgpool volumes: 7 day trend (not emailed)" print "= r125 aix errpt" ###print "= r129 tdp notes - summary " ###print "= r130 tdp notes - full (not emailed)" ###print "= r131 tdp notes - incremental (not emailed)" ###print "= r132 tdp notes - logs (not emailed)" print "= r140 session per node where count > 1 (not emailed) " print "= r141 q option (not emailed)" print "= r145 occupancy by server " print "= r150 occupancy by domain " print "= r152 occupancy by stgpool " print "= r153 occupancy by collocation group " print "= r155 occupancy by node (not emailed)" print "= r157 q audotocc (not emailed)" print "= r159 nodes locked (not emailed)" print "= r160 nodes with no associations" print "= r161 nodes with no associations EXCLUSION LIST" print "= r165 nodes never backed up (not emailed)" print "= r166 zzrt nodes with associations (not emailed)" print "= r167 nodes by collocation group (not emailed)" print "= r170 filespaces not backed up in 7 days (not emailed)" print "= r175 filespaces never backed up (not emailed)" print "= r180 server critical errors" print "= r184 backup objects and bytes per domain (not emailed)" print "= r185 backup objects and bytes per node (not emailed)" print "= r190 q vol for tape (not emailed)" print "= r195 q libvol (not emailed)" print "= r999 report end timestamp" -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco Post Sent: Thursday, January 29, 2015 6:07 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM rant > Op 29 jan. 2015, om 22:39 heeft Skylar Thompson <skyl...@u.washington.edu> > het volgende geschreven: > > TSM between v6.1 and the end of v6.2 was really rough, mostly related > to DB2. By v6.3 it got a lot more stable. I'm glad we upgraded from v5 > early, though, since we really benefit from DB2's improved indexing > and table compression - between two TSM instances we have close to 2 > billion file versions tracked by TSM. That would have overwhelmed any > v5 server, but we get by with relatively modestly-sized hardware. v5 was stable as a rock, but was going nowhere. All of the new features since 6.1 are possible thanks to DB2. And I vividly recall the days of TSM v4 where the day would start with yet another patch of the server and hoping that that version would run for more than 24 hours. And yes… I’m still waiting for somebody to explain why you need 64 GB of RAM for a medium sized server without deduce or replication. > > On Thu, Jan 29, 2015 at 09:29:53PM +0000, David Ehresman wrote: >> I've been admin TSM since the V3 days if memory serves, and sometimes it >> doesn't so much anymore. I've had a lot less problems with TSM since the >> move to DB2. We are now at 7.1.1. I do not know DB2 and have not had a need >> to learn it. We back up about 400 servers, 350 VMs, 100 databases, and an >> Exchange systems which is just big. FWIW, we do not do software (TSM) dedup. > > -- > -- Skylar Thompson (skyl...@u.washington.edu) > -- Genome Sciences Department, System Administrator > -- Foege Building S046, (206)-685-7354 > -- University of Washington School of Medicine -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622 ----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.