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 <Norman.Gee AT lc.ca DOT gov>
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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Nick Laflamme
> Sent: Friday, February 13, 2015 10:37 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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 <zforray AT vcu DOT edu>
> 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 <psz1 AT cornell DOT edu>
> 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: psz1 AT cornell DOT edu
> > > 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
> > zforray AT vcu DOT edu - 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
zforray AT vcu DOT edu - 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
|
