Shrinking large filesystem spanned across multiple luns

[KNR]

Hello, we have a mirrored/raid1 volume of 1TB spanned across two arrays (80 luns from each array) and its usage is now 400G (at some point usage was 850G). We need to shrink the filesystem to 500G so that we can utilize the space for new filesystem. I understand vxresize helps in this case and it will attempt to remove most recently added LUNs similar to stack LIFO mode. I am under impression that if the data extents are on the recently added LUN, that will be evacuated to free blocks on the old LUN and it will take considerable amount of time to complete the resize operation. I guess defragmenation prior the resize helps. I would like to know/estimate the resize operation time and wondering if there is any way to identify howmuch data is stored on a particular LUNs. 

Thanks in Advance.

[Daniel_Matheus · Accepted solution]

Hello Naani,

Defragmenting the file system prior to resize would be a good idea.

Please note that defrag can also take a lot of time depending on the fragmentation, number of files and whether or not there is I7O from an application on the file system.

For more information about defrag please see technote:

http://www.symantec.com/business/support/index?page=content&id=TECH162195

blocks used for indirects: 548704

    % Free blocks in extents smaller than 64 blks: 6.97

    % Free blocks in extents smaller than  8 blks: 2.04

    % blks allocated to extents 64 blks or larger: 83.17

what are blocks used for indirects:

VxFS allocates storage in groups of extents rather than a block at a time.   An extent is defined as one or more adjacent blocks of data within the file system.  A VxFS inode references 10 direct extents, each of which are pairs of starting block addresses and lengths in blocks.  After these 10 direct extents which point to data are used up, the file must use indirect extents which point to "pointers" (which in turn point to data) rather than data.

So if your file has less that 10 extents, then you don't need any indirect extents.

how fragmented is your file system?

 An unfragmented file system has the following characteristics:

• - Less than 1 percent of free space in extents of less than 8 blocks in length
• - Less than 5 percent of free space in extents of less than 64 blocks in length
• - More than 5 percent of the total file system size available as free extents in lengths of 64 or more blocks

A badly fragmented file system has one or more of the following characteristics:

• - Greater than 5 percent of free space in extents of less than 8 blocks in length
• - More than 50 percent of free space in extents of less than 64 blocks in length
• - Less than 5 percent of the total file system size available as free extents in lengths of 64 or more blocks

NOTICE: Please use the fsadm binary in /opt/VRTS/bin/fsadm, not the one in /sbin.

              In case you want to cancel the defragmentation always use kill -15 and then wait until defrag of the current file has been finished (this might also take several minutes or even hours depending on file size and fragmentation), if you kill the defrag process with -9 it will lead to a file system corruption.

Per default fsadm defrag will run 5 passes on each inode which can take a lot of time, so maybe use "-p" option to limit the number of passes (please see manpage for details)

Once defrag is completed you can resize the filesystem and volume using vxresize.

Unfortunately there is no way to tell you how long this might take, depending on the number of files and where they reside

and what load is on the file system it can take several hours to a day.

# vxresize  -F vxfs -g [disk group] -o verify [volume] [ new size]

# vxresize -b -F vxfs -g [disk group] [volume] [ new size]

if you log into your server through a terminal I'd recommend to use screen or nohup or similar and putting vxresize in background.

In case the terminal connection drops your volume or file system might be in an undesired state otherwise.

Thanks,
Dan