Home / server / Questions / 1050375
Accepted
Majid
Asked: 2021-01-19 23:17:00 +0800 CST

how to extend SAN storage in CentOS 7

  • 772

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

hard-drive linux extend

2 Answers

  1. Best Answer

    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.

    • 2

  2. Thank you for your time.
    In step 2 I used resizepart but I got this:
    Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Ignore/Cancel?
    Should I Fix it?

    This is the complete output 

    ~ # parted /dev/mapper/mpathc                                                                                                   
 GNU Parted 3.1
 Using /dev/mapper/mpathc
 Welcome to GNU Parted! Type 'help' to view a list of commands.
 (parted) p                                                                
 Error: The backup GPT table is not at the end of the disk, as it should  be.  This might mean that another operating system believes the
 disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)?
 Fix/Ignore/Cancel? I                                                      
 Warning: Not all of the space available to /dev/mapper/mpathc appears to be used, you can fix the GPT to use all of the space (an extra
 15032385536 blocks) or continue with the current setting? 
 Fix/Ignore? I                                                             
 Model: Linux device-mapper (multipath) (dm)
 Disk /dev/mapper/mpathc: 29.7TB
 Sector size (logical/physical): 512B/512B
 Partition Table: gpt
 Disk Flags: 

 Number  Start   End     Size    File system  Name  Flags
 1      4194kB  22.0TB  22.0TB  xfs

(parted) resizepart                                                       
Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the
disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? C
    • 0