1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

"Move data" from DISK to FILE pool - increased diskspace consumption by 25%?!

Discussion in 'TSM Operation' started by cmoeller, Apr 4, 2012.

  1. cmoeller

    cmoeller New Member

    Joined:
    Aug 17, 2011
    Messages:
    35
    Likes Received:
    0
    Hello!

    Our primary filelevel backup storagepool (called “filesrv”) is of DISK devclass and spans its volumes over several disk shelves, 18 TB altogether, 40 GB per volume. Now I’ve added a new, large shelf and wanted to use the opportunity to retire that pool and replace it with a sequential devclass FILE pool.

    To make use of aggregate reconstruction I did this:

    • Create two new FILE pools (“filesrv_seq” and “filesrv_seq_tmp”)
    • Used “move data” on two of the DISK volumes to “filesrv_seq_tmp”
    • Used “move data” of the new sequential volumes with reconstruct=yes to "filesrv_seq"

    The two DISK volumes were both full at 40GB each. The sequential pool however checks in at ~100GB now. That’s a 25% increase in diskspace consumption for the same data – and I have just no clue where that comes from. Can one of you guys tell me what happened or what I did wrong? Or is this to be expected and will level out over time?

    I'm a bit clueless right now and am considering to continue using "DISK" ... by the way, it's TSM 5.4 on a Windows 2003 machine.

    Thank you very much!


    Regards,
    Chris
     
  2.  
  3. moon-buddy

    moon-buddy Moderator

    Joined:
    Aug 24, 2005
    Messages:
    6,118
    Likes Received:
    274
    Occupation:
    Electronics Engineer, Security Professional
    Location:
    Somewhere in the US
    I believe the simple answer to the increase in space requirement is compression. If I remember right, sequential file type storage on disk does not compress the same way as data stored on random disk.

    I maybe wrong - anyone has some insights?
     
    Last edited: Apr 5, 2012
  4. chad_small

    chad_small Moderator

    Joined:
    Dec 17, 2002
    Messages:
    2,197
    Likes Received:
    43
    Occupation:
    AIX/SAN/TSM
    Location:
    Gilbert, AZ
    How many volumes made up the DISK pool and what is the file size for the file devclass?
     
  5. cmoeller

    cmoeller New Member

    Joined:
    Aug 17, 2011
    Messages:
    35
    Likes Received:
    0
    chad_small : the DISK pool currently spans 475 volumes at 40G each, the FILE devclasses are set to 50G volumes. Right now I have not moved more than two of the DISK pool volumes to the FILE pool because I'd like to clear things up first.

    moon-buddy : I guess that'd make sense but a 25% percent difference is pretty crazy imho. Even if we'd upgrade to TSM 6.x and use deduplication I'm sure we'd end up not under the DISK pool's diskspace consumption ...
     
  6. cmoeller

    cmoeller New Member

    Joined:
    Aug 17, 2011
    Messages:
    35
    Likes Received:
    0
    By the way - my current "working theory" is this:

    A logical "file" may be spread over several "DISK" volumes. This might be intentional for performance reasons (can anybody confirm?!) and will definately happen if a file will not fit a DISK volume. Now, on FILE volumes all files need to be "joined" since it's sequential access. So when issueing "move data" on a DISK volume what happens is that not only the bits and pieces of the volumes but in fact all logical files are moved, piecing together the data from possibly many DISK volumes. Which might very well result in the seemingly increased disk consumption.

    If that is correct the effect would "level out" once more volumes are moved from the DISK to the FILE pool.

    Any thoughts on this?
     
  7. moon-buddy

    moon-buddy Moderator

    Joined:
    Aug 24, 2005
    Messages:
    6,118
    Likes Received:
    274
    Occupation:
    Electronics Engineer, Security Professional
    Location:
    Somewhere in the US
    The thought of the data being spread among volumes in the disk pool is correct when running backups. This is done to speed things up. However, compression is also in effect.

    I still believe that the increase in sequential file space is simply because of reduced compression or total lack of it.
     

Share This Page