ADSM-L

Re: [ADSM-L] DEVCLASS=FILE - what am I missing

2015-02-13 13:47:03
Subject: Re: [ADSM-L] DEVCLASS=FILE - what am I missing
From: "Gee, Norman" <Norman.Gee AT LC.CA DOT GOV>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 13 Feb 2015 18:43:51 +0000
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
>