how to extend SAN storage in CentOS 7
I have a server with CentOS 7 using LUN for storing data. Recently Storage team has extended the LUN space. This is the output of multipath -ll
~ # multipath -ll
mpathc (3600601606cb04000a0eb35b80750eb11) dm-5 DGC ,VRAID
**size=27T** features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:2 sdl 8:176 active ready running
| `- 4:0:0:2 sdn 8:208 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 1:0:1:2 sdm 8:192 active ready running
`- 4:0:2:2 sdo 8:224 active ready running
The previous size of that was 20TB and now has extended to 27TB.
This is the output of fdisk coammnd
fdisk -l /dev/mapper/mpathc
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/mapper/mpathc: 29686.8 GB, 29686813949952 bytes, 57982058496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 4194304 bytes
Disk label type: gpt
Disk identifier: 843A6F7E-581A-455E-822F-2CE4306394BF
# Start End Size Type Name
1 8192 42949672926 20T Linux filesyste
You can see that the size and sectors of LUN is increased. this is the output of kpartx command
kpartx -l /dev/mapper/mpathc
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
mpathc1 : 0 42949664735 /dev/mapper/mpathc 8192
and this is the output of df command
df -h /dev/mapper/mpathc1
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/mpathc1 20T 17T 4.0T 81% /Splunk-Storage/COLD
So I can't figure out how can I extend the space of /dev/mapper/mpathc1 without loosing my data. I'm very appreciative for any suggestion Thanks in advance
Solution 1:
Step 1: Try rescanning the storage devices to tell the kernel that the size has changed. I am not sure if this has to be done for all the four components of the multipath, but it shouldn't hurt. You rescan storage devices by writing anything into their rescan file:
echo > /sys/class/block/sdl/device/rescan
echo > /sys/class/block/sdm/device/rescan
echo > /sys/class/block/sdn/device/rescan
echo > /sys/class/block/sdo/device/rescan
Scanning the HBAs should also work. SCSI HBAs have a scan file; you write three decimal numbers controller, target and LUN into it to scan that LUN. Or use wildcard "-" instead of a number. The following scans all devices on controller 0 on the two HBAs:
echo "0 - -" > /sys/class/scsi_host/host1/scan
echo "0 - -" > /sys/class/scsi_host/host4/scan
Step 2: At this point, the kernel knows that /dev/mapper/mpathc is 27TB. You will now have to increase the size of partition 1. The parted command can be used for resizing partitions, but I believe the Centos 7 version of parted doesn't have that feature. I would therefore unmount the filesystem, remove the partition (scary, I know), then create the partition again, this time with the correct size. Check that its parameters are correct.
umount /dev/mapper/mpathc1
parted /dev/mapper/mpathc1 rm 1 mkpart primary 0% 100% print
You may want to test that first on a disk that doesn't contain valuable data.
I don't know if it's possible to install a parted version that does have the resizepart command. It would make the second step easier.
The RHEL 7 storage manual contains a similar procedure with fdisk, but it assumes LVM, and no multipathing. After the fdisk procedure, you will probably have to use kpartx to inform the kernel about the changes on the disk. Thus, the parted approach seems easier, therefore safer to me.
Step 3: Increase the filesystem. First, mount it again. If it's XFS, you must mount it, then run xfs_growfs.
mount /dev/mapper/mpathc1 /Splunk-Storage/COLD
xfs_growfs /Splunk-Storage/COLD
If it's ext[234], run resize2fs. It can be mounted or unmounted.
resize2fs /dev/mapper/mpathc1
mount /dev/mapper/mpathc1 /Splunk-Storage/COLD
You are done.