Dear reader, Maybe that the access state is "unavaileble" try "q vol f=d"
look at the access state if it is not in a readw state use "update vol XXXX access=readwrite" Then do a move data on the volume to see if the remaining data moves Do a del vol and or a checkout if you want to lose the volume. Compression is automaticaly used when using format is drives. (Do not use client compression) Storage pools give a beter restore performance on file data if the contain less volumes ( this cuts on mount and search times ) Make a pool for priority restore nodes ( if possible with collocation ) Make a pool foor non priority nodes without collocation Make a pool for every type of TDP you install. ( colloction will cost you tapespace but will speed up restores ) ( the less volumes an uncollocated storage pool will have the faster the restores ) ( TDP pools have a beter restore performance because op the large sequentiall backups that kan stream back when restoring) Do not leave data on your diskpool longer then necessary. Further more one does not want to have backup data on a diskpool for longer than one backup cycle. after backup sessions do a: update stg diskpool hi=0 lo=0 and move data to tape and then offsite. Happy TSM'-ing. Greetz, Koen >From: "Cook, Dwight E" <[EMAIL PROTECTED]> >Reply-To: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: baffling tape, 3584 HW compression, and stgpool design >Date: Tue, 27 Aug 2002 04:30:37 -0700 > >Tapes like this generally become this way due to some error such as not >being able to read the volume's internal label when mounted to fill a >scratch request. >There is some TSM message that is along the lines of > "... making volume private to prevent further access..." >Now this doesn't mean the volume is ~bad~, might have been a drive problem. >Check the tape out, check it back in with a "checklabel=yes", if it can't >read the label, attempt to relabel it, if that fails, toss the tape... > >Dwight E. Cook >Software Application Engineer III >Science Applications International Corporation >509 S. Boston Ave. Suite 220 >Tulsa, Oklahoma 74103-4606 >Office (918) 732-7109 > > > >-----Original Message----- >From: Dan Foster [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, August 27, 2002 3:34 AM >To: [EMAIL PROTECTED] >Subject: baffling tape, 3584 HW compression, and stgpool design > > >Couple unrelated questions: > >1. When I query a 3570 library, there's one tape that baffles me: > >adsm> q libvol 3570lib1 > >Library Name Volume Name Status Last Use Home >Element >------------ ----------- ----------------- --------- >------------ >3570LIB1 133060 Private 34 > > I can't do anything with it -- ie, I can't discard the data on it >because > ADSM says it doesn't belong to a storage pool, and yet, no indication >that > it's a DbBackup. All other tapes in the library are sane and belongs to > either scratch, a storage pool, or a dbbackup. > > So what could it be, and how do I wipe that lone offending tape and >change > its status to scratch? (This is with ADSM 3.1+patches) > >2. How do I enable hardware compression for LTO tapes? Some sort of device > class or drive definition parameter? (This is with TSM 4.2.2+patches) > > I've looked through docs set and not finding anything that addresses >this. > > I'm currently using: > > tsm> DEFINE DEVCLASS 3584_DEVCLASS1 DEVTYPE=LTO FORMAT=DRIVE- > MOUNTLIMIT=10 MOUNTWAIT=60 MOUNTRETENTION=0 LIBRARY=3584LIB1 > > tsm> DEFINE DEVCLASS 3584_DEVCLASS2 DEVTYPE=LTO FORMAT=DRIVE- > MOUNTLIMIT=2 MOUNTWAIT=60 MOUNTRETENTION=0 LIBRARY=3584LIB1 > > The mountlimit of 10 and 2 is to put an hard upper bound on number > of drives that the backups (10) and offsite copying (2) can use. > > The mountwait of 60 minutes is to avoid having jobs fail if they're > sitting there, waiting for a particularly huge 300GB job to finish and > free up a drive for it to use. > > Mountretention=0 is because this is a fast automated library (3584 with > 12 drives); I can see setting it to 10 or so if it was a smaller human > operated library or requiring operator tape swaps like the 3570 >library. > > 3584LIB1 refers to the library, obviously. ;) (device /dev/smc0, etc) > > As I understand it, FORMAT=DRIVE means it uses the drive's compression > settings. I haven't seen any explicit mention of what this defaults to > nor how to adjust it in either the 3584 or TSM docs. > > Or would I use something like DEVTYPE=LTOC...? > >3. Is there really a reason to use multiple storage pools for the same > tape repository? > > Ie: the TSM 4.2 docs suggests an out-of-box default setup such as >DISKDIRS, > DISKDATA that then migrates to TAPEDATA, which then copies to OFFDIRS > and OFFDATA (offsite copy pool tapes). This makes sense. (I understand >the > purpose for each and every one of them, and how they're organized.) > > Is there a good reason why someone might want to split up diskdata and > tapedata into multiple stgpools? I ask because I've heard references to > other folks having multiple stgpools, and wondering what I'm missing >here. > > That's the only thing I think that eludes my understanding in preparing >the > new design, at this point. > >Any insight or comments much appreciated. Thanks! > >-Dan _________________________________________________________________ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.com
