Thanks for all the replies. Pretty much confirms that FILE isn't for me. We don't do dedupe and there are a lot of manual/monitoring processes involved (I have enough to do with 8-TSM servers I manage - don't need more).
Now to migrate 7TB of disk to tape so I can switch back to using DISK devclass.... On Fri, Feb 13, 2015 at 1:43 PM, Gee, Norman <[email protected]> wrote: > I front end several of my file device class pool with a disk device pool > which will migrate to the file device pool and control the number of > filling volumes. Volume that are in filling status will not reclaim, but > you can manually move the data. > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Nick Laflamme > Sent: Friday, February 13, 2015 10:37 AM > To: [email protected] > Subject: Re: DEVCLASS=FILE - what am I missing > > FILE allows deduplication; DISK doesn't. > > My impression after some experimenting is that FILE wasn't meant to replace > DISK; it was solely meant to replace tape device classes. We didn't need > to, so those experiments quietly ended. > > > On Fri, Feb 13, 2015 at 12:30 PM, Zoltan Forray <[email protected]> wrote: > > > WOW - I didn't realize that. Thanks for pointing that out. > > > > Won't automatically go to nextstgpool, didn't automatically reclaim? > So, > > what is the advantage/benefit of DEVCLASS=FILE? Sounds like time to go > > back to DEVCLASS=DISK > > > > On Fri, Feb 13, 2015 at 1:22 PM, Paul Zarnowski <[email protected]> > wrote: > > > > > At 12:12 PM 2/13/2015, Zoltan Forray wrote: > > > >Well, last night became a disaster. Backups failing all over because > it > > > >couldn't allocate any more files and also would not automatically > shift > > to > > > >use the "nextpool" which is defined as a tape pool. > > > > > > Alas, TSM doesn't automatically "roll over" when the ingest pool in > FILE. > > > I really wish that it did. Here's the relevant documentation for > NEXTSTG > > > for FILE stgpools: > > > > > > > When there is insufficient space available in the current storage > > > pool, the NEXTSTGPOOL parameter for sequential access storage pools > > does > > > not allow data to be stored into the next pool. In this case, the > > server > > > issues a message and the transaction fails. > > > > > > ..Paul > > > > > > > > > -- > > > Paul Zarnowski Ph: 607-255-4757 > > > Assistant Director for Storage Services Fx: 607-255-8521 > > > IT at Cornell / Infrastructure Em: [email protected] > > > 719 Rhodes Hall, Ithaca, NY 14853-3801 > > > > > > > > > > > -- > > *Zoltan Forray* > > TSM Software & Hardware Administrator > > BigBro / Hobbit / Xymon Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > [email protected] - 804-828-4807 > > Don't be a phishing victim - VCU and other reputable organizations will > > never use email to request that you reply with your password, social > > security number or confidential personal information. For more details > > visit http://infosecurity.vcu.edu/phishing.html > > > -- *Zoltan Forray* TSM Software & Hardware Administrator BigBro / Hobbit / Xymon Administrator Virginia Commonwealth University UCC/Office of Technology Services [email protected] - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
