targetcli extend fileio backend
Friday, April 3rd, 2020I am working on an article which will describe the procedures required to extend LUN on Linux storage clients, with and without use of multipath (device-mapper-multipath) and with and without partitioning (I tend to partition storage disks, even when this is not exactly required). Also – it will deal with migration from MBR to GPT partition layout, as part of this process.
During my lab experiments, I have created a dedicated Linux storage machine for this purpose. This is not my first, of course, and not likely my last either, however, one of the challenges I’ve had to confront was how to extend or resize in general an iSCSI LUN from the storage point of view. This is not as straight-forward as one might have expected.
My initial setup:
- Centos 7 or later is used.
- Using targetcli command-line (meaning – using LIO mechanism).
- I am using ZFS for the purpose of easily allocating block devices and files on filesystems. This is not a must – LVM can do just right.
- targetcli is using automatic saveconfig (default configuration).
I will not go over the whole process of setting up and running iSCSI target server. You can find this in so many guides around the web, such as this and that, as well as so many more. So, skipping that – we have a Linux providing three LUNs to another Linux over iSCSI. Currently – using a single network link.
Now comes the interesting part – if I want to expand/resize my LUN on the storage, there are several branches of possibilities.
Assuming we are using the ‘block’ backstore – there is nothing complicated about it – just extend the logical volume, or the ZFS volume, and you’re done with that. Here is an example:
LVM:
lvextend -L +1G /dev/storageVG/lun1ZFS:
zfs set volsize=11G storage/lun1 # volsize should be the final sizeExtremely simple. Starting at this point, LIO will know of the updated sizes, and will just notify any relevant party. The clients, of course, will need to rescan the iSCSI storage, and adept according to the methods in use (see my comment at the beginning of this post about my project).
It is as simple as that if using ‘fileio’ backstore with a block device. Although this is not the best recommended setup, it allows for (default) more aggressive write-back cache, and might reduce disk load. If this is how your backstore is defined (fileio + block device) – same procedure applies as before – extend the block device, and everyone is notified about it.
It becomes harder when using a real file as the ‘fileio’ backstore. By default, fileio will create a new file when defined, or use an existing one. It will use thin provisioning by default, which means it will not have the exact knowledge of the file’s size. Extending or shrinking the file, except for the possibility of data corruption, would have no impact.
Documentation about how to do is is non-existing. I have investigated it, and came to the following conclusion:
- It is a dangerous procedure, so do it at your own risk!
- It will result in a short IO failure because we will need to restart the service target.service
This is how it goes. Follow this short list and you shall win:
- Calculate the desired size in bytes.
- Copy to a backup the file /etc/target/saveconfig.json
- Edit the file, and identify the desired LUN – you can identify the file name/path
- Change the size from the specified size to the desired size
- Restart the target.service service
During the service restart all IO would fail, and client applications might get IO errors. It should be faster than the default iSCSI retransmission timeout, but this is not guaranteed. If using multipath (especially with queue_if_no_path flag) the likeness of this to affect your iSCSI clients is nearly zero. Make sure you test this on a non-production environment first, of course.
Hope it helps.