How to shrink Linux file-backed storage size in targetcli
772
I'm using targetcli to resize a iSCSI target. I've created a big FILEIO backstore, which is a waste of resources. Is it possible that I can shrink the file size without losing data?
You need to use the truncate command for this. Realize that truncate will chop off the end of the file at an offset that you specify, so you will loose data past that point if you have not resized the filesystem that this LUN provides on the iSCSI initiator side first (so that the filesystem contained therein is smaller than what you're truncating it to).
An example of this is here:
truncate -s SIZE /srv/totallyalun.img
SIZE may be (or may be an integer optionally followed by) one of following: KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.
This will resize the file in place. If the file is originally larger than the size specified via -s, truncate will chop off the end of it. If the file is smaller than the size specified, then truncate will extend your backing file thinly, with data at the end regions read as zeroes (as they will be holes).
Again, shrinking this is a great way to lose data if you don't make sure the filesystem inside that file (LUN) is smaller or exactly equal to the size you specify the backing store to be via truncation.
You can do this while the iscsi target is using the file with immediately readable results, provided the target is not configured to exclusively lock the file.
OR if you don't care about the data (or don't mind copying it), you can create a new thin file using sparse allocation and copy to that to avoid this whole mess in the first place. Thin allocation really does help with resource management, especially when dealing with software defined storage.
I would better stick with a good old data migration in this case.
I have tried -truncate myself but that time I ended with restoring from snapshot. Most probably, due to filesystem and logical volume size mismatch.
VMware, for example, developed a good set of tools that allow shrinking thick or thin virtual disks by zeroing the free space or removing zeros.
You need to use the truncate command for this. Realize that truncate will chop off the end of the file at an offset that you specify, so you will loose data past that point if you have not resized the filesystem that this LUN provides on the iSCSI initiator side first (so that the filesystem contained therein is smaller than what you're truncating it to).
An example of this is here:
truncate -s SIZE /srv/totallyalun.imgSIZE may be (or may be an integer optionally followed by) one of following: KB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.
This will resize the file in place. If the file is originally larger than the size specified via -s, truncate will chop off the end of it. If the file is smaller than the size specified, then truncate will extend your backing file thinly, with data at the end regions read as zeroes (as they will be holes).
Again, shrinking this is a great way to lose data if you don't make sure the filesystem inside that file (LUN) is smaller or exactly equal to the size you specify the backing store to be via truncation.
You can do this while the iscsi target is using the file with immediately readable results, provided the target is not configured to exclusively lock the file.
OR if you don't care about the data (or don't mind copying it), you can create a new thin file using sparse allocation and copy to that to avoid this whole mess in the first place. Thin allocation really does help with resource management, especially when dealing with software defined storage.