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