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

[cmoeller]

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

 

[moon-buddy]

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?

 

[chad_small]

How many volumes made up the DISK pool and what is the file size for the file devclass?

 

[cmoeller]

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 ...

 

[cmoeller]

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?

 

[moon-buddy]

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?

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.