2

My company is running a cloud hosting with CentOS. In the past, when it reached maximun SSD capacity, they upgraded it.

As far as I understand, they've done it by creating a primary partition and mounting it on /. So we ended with 4 primary partitions on sda.

Now I've upgraded again the space from 300GB to 400GB and I need to allocate those 100 extra GB.

What's the best thing I can do to add those 100GB?

Some info I've collected:

parted /dev/sda > print:

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  525MB   524MB   primary  xfs                  arranque
 2      525MB   85,9GB  85,4GB  primary                       lvm
 3      85,9GB  129GB   42,9GB  primary                       lvm
 4      129GB   322GB   193GB   primary                       lvm

fdisk /dev/sda > p:

Disk /dev/sda: 429.5 GB, 429496729600 bytes, 838860800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Identificador del disco: 0x000a2b1e

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048   167772159    83373056   8e  Linux LVM
/dev/sda3       167772160   251658239    41943040   8e  Linux LVM
/dev/sda4       251658240   629145599   188743680   8e  Linux LVM

df -h:

S.ficheros              Tamaño Usados  Disp Uso% Montado en
/dev/mapper/centos-root   298G   290G  8,4G  98% /
devtmpfs                  7,8G      0  7,8G   0% /dev
tmpfs                     7,8G      0  7,8G   0% /dev/shm
tmpfs                     7,8G    12M  7,8G   1% /run
tmpfs                     7,8G      0  7,8G   0% /sys/fs/cgroup
/dev/sda1                 497M   187M  311M  38% /boot
tmpfs                     1,6G      0  1,6G   0% /run/user/0

lsblk:

NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda               8:0    0   300G  0 disk 
├─sda1            8:1    0   500M  0 part /boot
├─sda2            8:2    0  79,5G  0 part 
│ ├─centos-swap 253:0    0     2G  0 lvm  [SWAP]
│ └─centos-root 253:1    0 297,5G  0 lvm  /
├─sda3            8:3    0    40G  0 part 
│ └─centos-root 253:1    0 297,5G  0 lvm  /
└─sda4            8:4    0   180G  0 part 
  └─centos-root 253:1    0 297,5G  0 lvm  /
sr0              11:0    1  1024M  0 rom  
2
  • You are using lvm so increase the size with lvm
    – Panther
    Jan 10 '19 at 17:37
  • Since you're already hitting the limit on the number of partitions, you will have to extend the last partition to take up all of the disk space. This blog post should be useful: thegeekdiary.com/…
    – Haxiel
    Jan 10 '19 at 17:49
1

Contrary to a comment seen on this question, as your partition table is Disk label type: dos, and not Disk label type: gpt, it is not possible to add a logical partition without first deleting a physical partition to have it act as logical partition container, since there are only 4 slots for physical partitions in MBR. Doing this without losing/corrupting data already in place is not trivial because the layout of logical partitions isn't exactly aligned the same as physical partitions: better not.

You can do what could have been done before (e.g. on the very first LVM partition, instead of adding new partitions), with a running system (at least if using xfs: CentOS' default, or ext4 and probably several other filesystems), without reboot nor downtime.

  • Have backups. Something can always go wrong (typo...).

  • Enlarge partition on disk

    The partition having room for enlargement is the last (because its blocks at least here, also occupy the last position on the disk). This is the most tricky part in my answer: using fdisk, note the start of partition 4, and delete partition 4. Note that this operation is done only in memory for now. Recreate a "new" primary partition 4 (as said above, don't try any logical partition), reuse the same partition start: this should be 251658240. Let it offer the whole remaining size to have it bigger.

    WARNING: newer fdisk tools might offer to wipe a detected partition signature, don't do it if asked now or when writing to disk: it detected your current PV/LVM signature.

    Put back partition type 8e (probably only cosmetic). If all is in order, write the new partition table and quit fdisk.

    UPDATE: To be clear the operation above is first done in memory. The overall result of deleting and recreating partition 4 at the same start position, done in fdisk's memory, is to have enlarged partition 4. When comitting this from fdisk to the disk, only the MBR (i.e.: the first sectors of the disk represented by /dev/sda) is re-written: there is no alteration of the data stored at sectors 251658240 and beyond. Higher level (GUI... or even parted) tools would offer an enlarge option (resizepart for parted), but the final result is the same. The partition 4 was never removed at any time from the disk (even if by mistake it was removed from disk, this would still not be fatal, as long as it's recreated at the same position and before the OS complains).

  • Update kernel view of the partition's new size

    Because the partition was in use (by the device mapper etc.) fdisk will certainly have complained that it couldn't have the system reread the partition table and that the old is still in use. To avoid a reboot, just use the right tool to update what changed: partx. It's simple here because only the size of the partition changed.

    # cat /sys/class/block/sda4/size
    188743680
    # partx -u /dev/sda4
    $ cat /sys/class/block/sda4/size
    [bigger value]
    

    Verify that the size is now increased and matches the result seen with fdisk. Else, something went wrong and reboot is probably needed.

  • Enlarge PV, LV, filesystem. Some LVM options might be able to chain those in a fewer commands, but here are all the steps

    Without option it will use all available space.

    # pvresize /dev/sda4
    

    The additional space on the PV is immediately made available on the VG for LV usage.

    # lvextend -l +100%FREE /dev/centos/root # or any other choice
    

    Then for xfs:

    # xfs_growfs / # remember that xfs may never shrink back
    

    Or ext4:

    # resize2fs /dev/centos/root # and ext4 can't be shrunk back while mounted
    
5
  • Answer made on SF with some similar steps: Expand full virtual debian disk to use empty space. That one is on GPT.
    – A.B
    Jan 10 '19 at 19:00
  • Thanks @A.B - While I can't try it yet, this seems to be a great and valid answer. I'll make a snapshop of the entire server and try to follow your steps next tuesday. Just to be sure: when I delete partition 4 and reuse the same start, will my data be intact or should I kind of snapshop that partition and restore it later? (if this is even possible).
    – Hache_raw
    Jan 11 '19 at 10:20
  • The data stays intact. I did this regularly after enlarging disks on VM. You have to be sure to reuse the same start, and to NOT wipe the "partition/filesystem/whatever signature" if the tool offers to do that. Anyway, you have to plan for failure (backups) for such things. You could even try it on a VM to test.
    – A.B
    Jan 11 '19 at 10:45
  • updated answer, telling that data isn't changed, only MBR
    – A.B
    Jan 11 '19 at 11:21
  • You saved my life! It worked like a charm. In case someone needs it: while using fdisk: d for delete, n for new partition, t to change partition type, p to check changes, w to write changes.
    – Hache_raw
    Jan 15 '19 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.