ADSM-L

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

2015-02-13 13:17:43
Subject: Re: [ADSM-L] DEVCLASS=FILE - what am I missing
From: Steven Langdale <steven.langdale AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 13 Feb 2015 18:16:03 +0000
As the number of vols is damn close to Max scratch. I'd say you ran out.
No thing in actlog?  Bung it up and see what happens.

On Fri, 13 Feb 2015 17:15 Zoltan Forray <zforray AT vcu DOT edu> wrote:

> Up until recently, I have always used DEVCLASS=DISK for disk storage and
> always preformatted/allocated the disk volumes into multiple chunks to all
> for multi-I/O benefits.
>
> When I recently stood-up a new server, I decided to try DEVCLASS=FILE for
> disk-based storage/incoming backups.
>
> I thought I understood that FILE type storage was basically
> "tape/sequential files on disk" and would act accordingly and things like
> reclamation now applied so when the file chunks (I defined 50GB file sizes)
> got below the reclaim value, it would reclaim such files, create new ones
> and delete the old ones automagically.
>
> 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.
>
> So, what am I doing wrong?  What assumptions are wrong?  Here is the
> devclass values with the empty values left out...:
>
>              Device Class Name: TSMFS
>         Device Access Strategy: Sequential
>             Storage Pool Count: 1
>                    Device Type: FILE
>                         Format: DRIVE
>          Est/Max Capacity (MB): 51,200.0
>                    Mount Limit: 40
>                      Directory: /tsmpool
>
> Here is the lone stgpool that used this devclass:
>
> 12:06:21 PM   GALAXY : q stg backuppool f=d
>                     Storage Pool Name: BACKUPPOOL
>                     Storage Pool Type: Primary
>                     Device Class Name: TSMFS
>                    Estimated Capacity: 7,106 G
>                    Space Trigger Util: 84.5
>                              Pct Util: 80.9
>                              Pct Migr: 80.9
>                           Pct Logical: 99.2
>                          High Mig Pct: 85
>                           Low Mig Pct: 75
>                       Migration Delay: 0
>                    Migration Continue: Yes
>                   Migration Processes: 1
>                 Reclamation Processes: 1
>                     Next Storage Pool: PRIMARY-ONSITE
>                  Reclaim Storage Pool:
>                Maximum Size Threshold: No Limit
>                                Access: Read/Write
>                           Description:
>                     Overflow Location:
>                 Cache Migrated Files?:
>                            Collocate?: No
>                 Reclamation Threshold: 59
>             Offsite Reclamation Limit:
>       Maximum Scratch Volumes Allowed: 143
>        Number of Scratch Volumes Used: 137
>         Delay Period for Volume Reuse: 0 Day(s)
>                Migration in Progress?: No
>                  Amount Migrated (MB): 0.00
>      Elapsed Migration Time (seconds): 1,009
>              Reclamation in Progress?: No
>        Last Update by (administrator): ZFORRAY
>                 Last Update Date/Time: 02/13/2015 11:44:23
>              Storage Pool Data Format: Native
>                  Copy Storage Pool(s):
>                   Active Data Pool(s):
>               Continue Copy on Error?: Yes
>                              CRC Data: No
>                      Reclamation Type: Threshold
>           Overwrite Data when Deleted:
>                     Deduplicate Data?: No
>  Processes For Identifying Duplicates:
>             Duplicate Data Not Stored:
>                        Auto-copy Mode: Client
> Contains Data Deduplicated by Client?: No
>
> I calculated the "Max Scratch Volumes" value based on having ~7.6TB
> filesystem so 50GB * 143 = 7.1TB
>
> This morning when I checked, there were plenty of volumes with <40%
> utilized.  SO why didn't reclaim kick-in?  or am I totally off on this
> assumption?   I manually performed move data on them and it freed things
> up.
> --
> *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
>