A few questions and a thought here.
1. Can you confirm how many sessions are running with "q sess".
Only my session is running
tsm: TSM_PROD01>q sess
------ ------ ------ ------ ------- ------- ----- -------- --------------------
25 Tcp/Ip Run 0 S 203 196 Admin Linux86 ADMIN
2. Post the output of "q mount", "show asqueued"
No Mounts
q mount
ANR2034E QUERY MOUNT: No match found using this criteria.
3. Can you post the output of "df -k /opt/tivoli/tsm/stg01" (unix command)
df -h /opt/tivoli/tsm/stg01
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VG_DATA-LV_STG01
670G 31G 605G 5% /opt/tivoli/tsm/stg01
4. Post the output of "ulimit -a" (unix command)
[root@mp-man-l-p1 Colin_Dont_delete]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 38911
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 38911
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
5. Can you confirm the destination of all your management classes points to the filepool and not to the diskpool (which has no space allocated to it). (I don't think this is the cause but better to check).
Yep they all seem to pont to the filepool
Policy Domain Name: PROD
Policy Set Name: ACTIVE
Mgmt Class Name: P-MC-MT
Default Mgmt Class ?: No
Description: Production MC Monthly
Space Management Technique: None
Auto-Migrate on Non-Use: 0
Migration Requires Backup?: Yes
Migration Destination: FILE_STG01
Last Update by (administrator): ADMIN
Last Update Date/Time: 09/17/2008 17:57:47
Managing profile:
Changes Pending: No
Policy Domain Name: PROD
Policy Set Name: ACTIVE
Mgmt Class Name: P-MC-WK
Default Mgmt Class ?: Yes
Description: Production MC Weekly
Space Management Technique: None
Auto-Migrate on Non-Use: 0
Migration Requires Backup?: Yes
Migration Destination: FILE_STG01
Last Update by (administrator): ADMIN
Last Update Date/Time: 09/17/2008 17:49:26
Managing profile:
Changes Pending: No
Policy Domain Name: PROD
Policy Set Name: PRODUCTION
Mgmt Class Name: P-MC-MT
Default Mgmt Class ?: No
Description: Production MC Monthly
Space Management Technique: None
Auto-Migrate on Non-Use: 0
more... (<ENTER> to continue, 'C' to cancel)
Migration Requires Backup?: Yes
Migration Destination: FILE_STG01
Last Update by (administrator): ADMIN
Last Update Date/Time: 09/17/2008 17:57:47
Managing profile:
Changes Pending: No
Policy Domain Name: PROD
Policy Set Name: PRODUCTION
Mgmt Class Name: P-MC-WK
Default Mgmt Class ?: Yes
Description: Production MC Weekly
Space Management Technique: None
Auto-Migrate on Non-Use: 0
Migration Requires Backup?: Yes
Migration Destination: FILE_STG01
Last Update by (administrator): ADMIN
Last Update Date/Time: 09/17/2008 17:49:26
Managing profile:
Changes Pending: No
Now the thought...
When you audited that volume you got mount requests for a *lot* of other volumes. This is probably because you have used the default 2GB size for that device class instead of choosing a more appropriate larger size (eg. 100GB). There is probably a single large file (or more) spanned across these volumes, and it will need to mount them all for the audit, maybe it is trying to mount them all at the same time? Possibly increasing the mount limit to > the number of volumes in the filepool will let you access them all, in order for you to migrate to a larger maxsize for the volumes if this is what the issue is.