Results 1 to 4 of 4
  1. #1
    Member
    Join Date
    May 2004
    Location
    Victoria, Australia
    Posts
    167
    Thanks
    3
    Thanked 0 Times in 0 Posts

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

    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

  2. #2
    Member
    Join Date
    May 2004
    Location
    Victoria, Australia
    Posts
    167
    Thanks
    3
    Thanked 0 Times in 0 Posts

    Default

    Think I'll try logging this with IBM as this is a weird one ....

  3. #3
    Senior Member
    Join Date
    Jun 2006
    Posts
    556
    Thanks
    0
    Thanked 15 Times in 14 Posts

    Default

    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

  4. The Following User Says Thank You to Efim For This Useful Post:

    jharris (05-27-2013)

  5. #4
    Member
    Join Date
    May 2004
    Location
    Victoria, Australia
    Posts
    167
    Thanks
    3
    Thanked 0 Times in 0 Posts

    Default

    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/docvie...id=swg21225710

Similar Threads

  1. Retrieve from Tape to Sequential File
    By abitran in forum TSM Installation, Upgrade and Configuration
    Replies: 3
    Last Post: 02-06-2012, 09:05 AM
  2. Modify a Sequential Access Storage Pool
    By rallingham in forum TSM Installation, Upgrade and Configuration
    Replies: 2
    Last Post: 07-15-2010, 01:16 PM
  3. Sequential Media Storage Pool Problem
    By scottgassTSM in forum Tape / Media Library
    Replies: 0
    Last Post: 05-30-2007, 10:56 AM
  4. Replies: 1
    Last Post: 01-13-2005, 09:42 AM
  5. Big problem with backing up on Sequential Access Storage Pool volumes
    By zaxxon in forum Backup / Archive Discussion
    Replies: 2
    Last Post: 07-14-2003, 03:28 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •