Expand a StorNext LUN
Until recently, the only supported way to expand storage in a StorNext file system was to add a stripe group. New array technology now makes it possible in some cases to expand a LUN by adding more storage to the underlying volume. This topic provides the procedure for expanding a LUN. LUN expansion is supported beginning with StorNext 6.
Note: For the purposes of this topic, the terms volume and LUN are used interchangeably.

- Clients and FSM must be running at StorNext 6.0 (and later).
-
All clients must have multipath configured appropriately.
- Windows and Linux clients can dynamically resize the StorNext file system without unmounting. With other clients (including macOS Xsan), you might have to unmount the file system prior to resize, and then remount the file system after resizing.
- If a StorNext stripe group has more than one volume, all the volumes in the stripe group must be expanded to the same size.

The volume expansion process consists of several tasks that need to be completed in sequence. This is a bottom up process that begins in the array and pushes up into the FSM and clients.
- Expand the Volume on the QXS Array
-
Unmount StorNext file systems on non-Linux, Windows, or StorNext clients that are running StorNext 5.4.0.1 (or earlier).
Note: With other clients (including macOS Xsan), you might have to unmount the file system prior to resize, and then remount the file system after resizing.
- Update Linux to the New Size
- Rewrite the StorNext Label(s) to Reflect the Size Change
- Update the file system configuration to reflect the size change.
- Instantiate the new configuration in the FSM.
- Resize the StorNext Stripe Group on an Active File System
- Resize the StorNext Stripe Group on an Inactive File System

This task assumes basic knowledge of the QXS array Web Based Interface (WBI). In this example, we will expand a StorNext data volume by 100 GBytes, effectively doubling its size.
- Log in to the array and select volumes from the left column.
- Select the volume to expand.
- Click below on the selected volume
- In the Action menu, click Modify Volume.
- In the Expand By field, input the desired amount.
- Click OK.
Note: StorNext requires all the volumes in a stripe group to be the same size. If there is more than one volume that you need to expand, do so now.
Caution: Over-provisioning is not recommended because unmap/trim is not fully supported in StorNext. Verify that your volumes do not exceed the physical storage available.

The Linux block device stack hot-plug infrastructure does not automatically update the size of SCSI device when it is changed. You must explicitly force a rescan of the SCSI devices so they incorporate the new size. A utility, sn_scsi_resize, initiates a rescan of all SCSI block devices based on their DM/Multipath instantiation. The utility, sn_scsi_resize, also executes a StorNext “disks refresh” command via cvadmin.
Important
On a StorNext appliance, you must execute the utility, sn_scsi_resize, on both nodes of the HA pair.

-
Execute the command,
cvlabel –l
; you have resized snfs_data_qx1_L2.Note: The Sectors field and the Maximum sectors field are different. The Sectors field refers to the value from the disk label, and the Maximum sectors field refers to the actual size of the volume.
per1-# cvlabel -l
/dev/mapper/mpatha [Quantum StorNext QX G22x] SNFS-EFI " snfs_data_qx1_L2"Sectors: 195287007.
Sector Size: 512. Maximum sectors: 390592479. Stripebreadth: 0.
/dev/mapper/mpathb [Quantum StorNext QX G22x] SNFS-EFI "snfs_data_qx1_L3"Sectors: 195287007.
Sector Size: 512. Maximum sectors: 195287007. Stripebreadth: 0.
/dev/mapper/mpathc [Quantum StorNext QX G22x] SNFS-EFI "snfs_data_qx1_L4"Sectors: 390592479.
Sector Size: 512. Maximum sectors: 390592479. Stripebreadth: 0.
/dev/mapper/mpathd [Quantum StorNext QX G22x] SNFS-EFI "snfs_meta_qx1_L5"Sectors: 195287007.
Sector Size: 512. Maximum sectors: 195287007. Stripebreadth: 0. -
The new size is 390592479; you must re-label the volume with the new size.
per1-# cvlabel -c | grep mpatha >/tmp/label
per1-# cat /tmp/label
snfs_data_qx1_L2 /dev/mapper/mpatha 195287007 EFI 0 # host 0 lun 2 sectors 195287007 sector_size 512
inquiry [Quantum StorNext QX G22x] serial 600C0FF0001BE35788018F5801000000 -
Edit the label file and change the sectors field to reflect the new size.
per1-# cat /tmp/label
snfs_data_qx1_L2 /dev/mapper/mpatha 3907010703 EFI 0 # host 0 lun 2 sectors 195287007 sector_size 512
inquiry [Quantum StorNext QX G22x] serial 600C0FF0001BE35788018F5801000000 -
Rewrite the label.
per1-# cvlabel -r /tmp/label
*WARNING* This program will over-write volume labels on the devices specified in the file "/tmp/label". After execution, the devices will only be usable by the StorNext. You will have to re-partition the devices to use them on a different file system.
Do you want to proceed? (Y / N) -> y
/dev/mapper/mpatha [Quantum StorNext QX G22x] SNFS-EFI "snfs_data_qx1_L2" Controller '208000C0FF1A60DA', Serial '600C0FF0001BE35788018F5801000000', Sector Size 512, Sectors 195287007 (100.0GB), Max 390592479, Stripebreadth 0, GUID 9ab6057c-e6fe-11e6-ba37-0024e8636400 [Mon Jan 30 09:13:07 2017 00:24:e8:63:64:00]The disk /dev/mapper/mpatha has a valid label, and is changing from 195287007 to 390592479 sectors.
Do you want to re-label it SNFS-EFI - Name: snfs_data_qx1_L2 Sectors: 390592479 (Y / N) -> y
New Volume Label -Device: /dev/mapper/mpatha SNFS Label: snfs_data_qx1_L2 Sectors: 390592479.
Done. 1 source lines. 1 labels.
Requesting disk rescan . -
Verify the label change.
per1-# cvlabel -l | grep mpatha
/dev/mapper/mpatha [Quantum StorNext QX G22x] SNFS-EFI "snfs_data_qx1_L2"Sectors: 390592479. Sector Size: 512. Maximum sectors: 390592479. Stripebreadth: 0.

On an active file system, execute the command, sgmanage
, to resize an active file system. You must provide the file system name and the stripe group name.
fs: jhb Active: yes Port: 48299 Pid: 16383 IP: 10.65.186.149
Stripe Group 1 [DataFiles0]
Status : Up, AllocTrue
Total blocks : 24410112
Free blocks : 24410112
Reserved blocks : 1082880
Allocated blocks : 0 - (0.00% full)
Disk stripes : Read: Enabled, Write: Enabled
Node: 0, Name: snfs_data_qx1_L2, Label: QXDATA
Sectors: 195287007
Resize FSM jhb SG DataFiles0 [1]
New sector count: 390592479
Are you sure you want to continue [y/n]? y
Stripe Group 1 [DataFiles0]
Status : Up, AllocTrue
Total blocks : 48823296
Free blocks : 48823296
Reserved blocks : 1082880
Allocated blocks : 0 - (0.00% full)
Disk stripes : Read: Enabled, Write: Enabled
Node: 0, Name: snfs_data_qx1_L2, Label: GENERIC_390592479_512
Sectors: 390592479
The command, sgmanage
, updates the on-disk configuration file, the file system configuration file /usr/cvfs/config/<fsname>.cfgx and the internal FSM tables.

On an inactive file system, execute the command cvupdatefs –s <fsname>
.
- Edit the file system configuration file, /usr/cvfs/config/<fsname>.cfgx, so that the new size is reflected in the appropriate stripe group(s).
-
Execute the following command:
cvupdatefs –s <fsname>

If the stripe group is a StorNext data stripe group, the new size should be reflected by the command, df. Below are examples of the output from the command, df, before and after for the mounted file system.
Before:
Filesystem 512B-blocks Used Available Use% Mounted on
jhb 195280896 8663040 186617856 5% /jhb
After:
Filesystem 512B-blocks Used Available Use% Mounted on
jhb 390586368 8663040 381923328 3% /jhb
If the stripe group is a StorNext metadata stripe group, you can see the new size by executing the command, cvadmin
; the option is show <stripe_group_name>
or disks
.

- Verify the command output for, cvlablel –L does not report unusable on the expanded LUN.
- In cases where the LUN reports unusable, run the command, /usr/cvfs/bin/sn_scsi_resize, on that client.
- Clients, such as Ubuntu 14.04, require the multi-path driver be restarted, service multipath‐tools restart, and /usr/cvfs/bin/sn_scsi_resize to acknowledge the updated LUN size.
-
Reboot the system if the size is incorrect, if operations are hanging or unresponsive, or if operations are failing.