disk pool has files that won't migrate to tape

[JonRoenick]

Here are the relevant portions of 2 queries.

q stg
Storage      Device       Estimated    Pct    Pct  High  Low  Next Stora-
Pool Name    Class Name    Capacity   Util   Migr   Mig  Mig  ge Pool    
                                                    Pct  Pct  
-----------  ----------  ----------  -----  -----  ----  ---  -----------
DISK01       DISK             600 G    0.7    0.7    90   60  TAPE01

q vol stg=disk01
Volume Name               Storage      Device      Estimated    Pct   Volume 
                          Pool Name    Class Name   Capacity   Util   Status 
------------------------  -----------  ----------  ---------  -----  --------
/disk01/disk01.dsm        DISK01       DISK           20.0 G   12.9  On-Line 
/disk01/disk02.dsm        DISK01       DISK           20.0 G    0.0  On-Line 
/disk01/disk03.dsm        DISK01       DISK           20.0 G    8.5  On-Line

I can start a migration process just fine, tapes will mount just fine, but no data past that 0.7 mark will migrate off the disk01 pool. I can put more data into the pool and it migrates just fine, but i just can't get these files off disk01.dsm and disk03.dsm. Is there anything i can do or will i just have to delete these volumes and lose the data on them?

[Raakin]

Any (error) messages in the activity log concerning these files/volumes?
Have you determined what files are not migrating? Which node holds the source file(s)? Are they business critical?
Are they the latest version (vs. an inactive version) of the source file?

Answers to these questions should help guide you in determining if you can delete them vs. trying to perform other actions.
Last time I had something similar I ended up doing a sub audit process... I'll have to look back in my notes for what I did but it was much MUCH less time than a full blown DB audit.

[JonRoenick]

No error messages at all, other than the migration processes timing out since i run them with dur=120. If i don't use the dur=120, then the migration will literally never end and never dismount the tapes since they are "In Use" without data moving to them. I don't know what the files are on those volumes, nor do i know what nodes have data on those volumes--is there a way to find out?

This stg pool, disk01, is used just for small SQL .bak and .trn files, but the management class only holds them for a week anyway, so they aren't really "critical" since i already have more updated versions of whatever files are here.

[Raakin]

No error messages means you don't need a TSM DB audit.
Sure there are ways to look at the contents of the disk01 volume BUT if you know they are not critical then why go through the effort to find them. If you are unsure if they are critical then go down that route.

One last thought is do you have a migration delay set? 'q stg disk01 f=d'

[JonRoenick]

No delay setting

q stg disk01 f=d
                    Storage Pool Name: DISK01
                    Storage Pool Type: Primary
                    Device Class Name: DISK
                   Estimated Capacity: 600 G
                   Space Trigger Util: 1.0
                             Pct Util: 1.0
                             Pct Migr: 1.0
                          Pct Logical: 100.0
                         High Mig Pct: 90
                          Low Mig Pct: 60
                      Migration Delay: 0
                   Migration Continue: Yes
                  Migration Processes: 2
                Reclamation Processes: 
                    Next Storage Pool: TAPE01
                 Reclaim Storage Pool: 
               Maximum Size Threshold: No Limit
                               Access: Read/Write
                          Description: 
                    Overflow Location: 
                Cache Migrated Files?: No
                           Collocate?: 
                Reclamation Threshold: 
            Offsite Reclamation Limit: 
      Maximum Scratch Volumes Allowed: 
       Number of Scratch Volumes Used: 
        Delay Period for Volume Reuse: 
               Migration in Progress?: No
                 Amount Migrated (MB): 23,192.21
     Elapsed Migration Time (seconds): 1,200
             Reclamation in Progress?: 
       Last Update by (administrator): JROENICK
                Last Update Date/Time: 03/21/2011 16:23:02
             Storage Pool Data Format: Native
                 Copy Storage Pool(s): 
                  Active Data Pool(s): 
              Continue Copy on Error?: Yes
                             CRC Data: No
                     Reclamation Type: 
          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

[Raakin]

Ok, I am out of ideas of anything legitimate that would keep that data in there.
I do not know of other impact deleting the volumes will have.

[budwiser]

How long has this been going on? Could it be that you have cached data still sitting on that drive that has not expired yet. look up the meaning for space trigger util from your q stg command

[JonRoenick]

It been going on for about 2 weeks. I put in a PMR and it was escalated to level 2 with a lot of traces, but no success.

[paschumacher]

Did you have caching enabled on this pool in the past at some point? I enabled caching on a pool, then disabled it several months later and ran into this problem where the data stays there and won't migrate out. It was determined by support that it was cached files. I ended up having to delete the volumes with discarddata=yes

[JonRoenick]

Nope, never had caching turned on for any of my diskpools. Did you have to delete every volume in the pool or just the one(s) that had cached data?

[paschumacher]

just had to delete the ones with cached data. if you have never turned on disk caching, then turned it off like i did, this probably isn't the same issue. figured i would ask, sorry i dont have a better answer for you.