TSM v6.3 on AIX 7.1 Sequential File Pool Anomoly....

Status
Not open for further replies.

jharris

ADSM.ORG Member
Joined
May 24, 2004
Messages
166
Reaction score
0
Points
0
Location
Victoria, Australia
Website
Visit site
I have a sequential file pool 'DIR_BAK_E_F' used just for DIR_MC objects and it rapidly ran out of scratch volumes.

Upon inspection I noticed that the volumes were not reaching their maximum capacity, before being 100% full and a new file volume was created. I inspected the file system and the files appear to be created to the correct size of the device class, but query volume shows that these volumes are full with hardly no utilisation. I then moved the data from one of those FULL volumes and the process completes showing only around 12MB copied.

Any idea's why the volumes aren't storing the maximum amount of data as defined by the device class?

Some details below:
4:44:46 PM DDVTSM01 : q stg DIR_BAK_E_F
Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
DIR_BAK_E_F DIR_MC 21 G 0.3 0.3 90 70



4:37:13 PM DDVTSM01 : q vol stgp=DIR_BAK_E_F
Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
/tsmstg/dir_mc/0000024F- DIR_BAK_E_F DIR_MC 15.0 M 100.0 Full
.BFS
/tsmstg/dir_mc/00000250- DIR_BAK_E_F DIR_MC 12.7 M 100.0 Full
.BFS
/tsmstg/dir_mc/00000251- DIR_BAK_E_F DIR_MC 20.2 M 100.0 Full
.BFS
/tsmstg/dir_mc/00000252- DIR_BAK_E_F DIR_MC 11.3 M 100.0 Full
.BFS
/tsmstg/dir_mc/00000253- DIR_BAK_E_F DIR_MC 1,024.0 M 0.1 Filling
.BFS


root@ddvtsm01 /tsmstg/dir_mc #l
total 12652120
drwxrwxr-x 2 root tsmsrvrs 4096 May 20 16:38 .
drwxrwxr-x 21 root tsmsrvrs 4096 May 10 12:14 ..
-rw------- 1 tsminst1 tsmsrvrs 1073741824 May 20 16:28 00000250.bfs
-rw------- 1 tsminst1 tsmsrvrs 1073741824 May 20 16:28 00000251.bfs
-rw------- 1 tsminst1 tsmsrvrs 1073741824 May 20 16:36 00000252.bfs
-rw------- 1 tsminst1 tsmsrvrs 1073741824 May 20 16:38 00000253.bfs
-rw------- 1 tsminst1 tsmsrvrs 85721088 May 20 16:38 00000254.bfs
-rw------- 1 tsminst1 tsmsrvrs 2097152000 May 19 22:41 dir_bak_e_d.vol


05/20/2013 16:36:50 ANR0515I Process 163 closed volume
/tsmstg/dir_mc/00000253.BFS. (SESSION: 9154, PROCESS:
163)
05/20/2013 16:36:50 ANR0986I Process 163 for MOVE DATA running in the
BACKGROUND processed 17,413 items for a total of
12,543,874 bytes with a completion state of SUCCESS at
16:36:50. (SESSION: 9154, PROCESS: 163)




4:43:11 PM DDVTSM01 : q devc dir_mc f=d
Device Class Name: DIR_MC
Device Access Strategy: Sequential
Storage Pool Count: 1
Device Type: FILE
Format: DRIVE
Est/Max Capacity (MB): 1,024.0
Mount Limit: 100
Mount Wait (min):
Mount Retention (min):
Label Prefix:
Library:
Directory: /tsmstg/dir_mc
Server Name:
Retry Period:
Retry Interval:
Shared:
High-level Address:
Minimum Capacity:
WORM: No
Drive Encryption:
Scaled Capacity:
Primary Allocation (MB):
Secondary Allocation (MB):
Compression:
Retention:
Protection:
Expiration Date:
Unit:
Logical Block Protection:
Last Update by (administrator): ADMXXXX
Last Update Date/Time: 05/20/2013 16:08:44




/etc/security/limits file, root and tsminst1 unlimited file size.
root:
fsize = -1
data = -1
stack = -1
core = -1
rss = -1
nofiles = -1

tsminst1:
fsize = -1
data = -1
stack = -1
core = -1
rss = -1
nofiles = -1
 
Hi,
Device type FILE use 256KB block size (I think).
Try to multiply the number of objects on the block size.
Also you can use NONblock format for this pool for DIRMC data.
Efim
 
Thanks Efim ... you're right on the money. I hadn't even thought of the nonblock data format for dirmc file pools.

The problem has now been fixed and I've moved all of the old files now into a single 200MB file which is 40% utilised.
(PS. There were 69,877 dir objects migrated multiply that by 256KB for the old stg pool and that equated to 17.8GB previously occupied by the same DIRMC seq file pool!!!)

Here's the IBM technote:
FILE device type inefficient space usage for directory data.
http://www-01.ibm.com/support/docview.wss?uid=swg21225710
 
Status
Not open for further replies.
Back
Top