LVM extend Filesystem: new partition vs. grow existing one

I need often to expand a filesystem on a RHEL7-System which runs on VMWare-ESX 6. Normally, i resize the existing virtual disk and run the following cmds:

1. echo "1" > /sys/class/scsi_disk/0:0:X:X/device/rescan
2. pvresize /dev/sdX
3. lvextend -l+100%FREE [VolumeGroup]
4. resize2fs [MountPoint]

I think this is a convenient solution, but RedHat, VMWare and the majority of other How2s i`ve found, use another way. They create a new partition and add it to the volumegroup instead resize an existing one.

see:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006371

https://access.redhat.com/solutions/24770

I can't forecast the need of space, so i had to resize pretty often, but i don`t want to create a new partition everytime. There has to be a reason why they use and prefer the second method, which i think, is the worse one. Can anyone tell me why?

kind regards Sascha

Solution 1:

Actually in your link to the RedHat article step one says:

Create a physical volume from a free disk or partition (e.g. /dev/sdc1 as a partition)

And in the link for the VMWare article, there is a note at the top:

Note: These steps only apply to EXT3 file systems.

So you can do either/or. The recommended way in almost all cases (as of RHEL7/GRUB2 -- sorry I can't speak for VMWare) is to NOT make a partition as you're then creating a scheme like below.

Disk
|- MBR
|- |- LVM 
|- |- |- Superblock

There was at one time alignment issues by not partitioning, which causes a performance penalty, however you can compensate for the missing partition in LVM for systems that supposedly require one.

The recommendation to partition used to be based on the fact that other OS's won't be able to read the LVM metadata and since there is no partition, will show the disk as being unformatted instead of showing it as having a partition. Actually, even in Linux, if there is no partition, the disk appears to be unused to all of the partitionin tools (fdisk, gdisk, parted, etc). That is because they are designed to look for partitions.

If you're running VMware, I'm assuming you're working with a corporate environment where there are controls in place -- SA's won't have any reason to be monkeying with partitions, and you would never have Windows nor any "other OS" installed onto the machine unless the machine was being repurposed. Therefore, the recommendation to partition does not apply.

The best practice in older versions of RHEL was to partition: https://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-adding-disks-in-lvm

The revised recommendation of using the whole disk is of course new to RHEL 7, as older systems use GRUB instead of GRUB2. On those older systems the reason to keep partitioning is due to /boot needing to be on a physical disk.

In your case, you're not referring to the OS disks, so even in older systems you can safely keep the LVM metadata directly on the raw disk without any partition.

There is one case where you will want to use a protective MBR, and that is when you are using a LVM on a physical drive in a guest OS, instead of using a vmdk or other type of file. But even as noted by @shodanshok you can use the filter in lvm.conf on the hypervisor to hide those.

If this is a SAN backed physical disk, there is a discussion here: https://access.redhat.com/discussions/1488023

Oracle DBAs also recommend using the raw disk: http://www.dba-oracle.com/real_application_clusters_rac_grid/raw_devices_linux.html

Finally, there is a discussion about this on Reddit as well: https://www.reddit.com/r/sysadmin/comments/292qf2/lvm_physical_disk_vs_partitions/

Pretty much everyone agrees, use the whole disk.

Further reading about booting from an LVM backed disk, if you're interested. https://unix.stackexchange.com/questions/136614/how-does-grub2-load-the-kernel-from-an-lvm-volume

http://forums.fedoraforum.org/showthread.php?t=263325

So to summarize: Use the whole disk. One day, partitioning tools could possibly phased out of use in *nix entirely, in favor of things like zfs tools, btrfs tools, lvm, or some combination of the three.

Solution 2:

Based on your commands, you are using a raw device as physical volume. While perfectly fine, Red Hat generally recommend to create a protective MBR (ie: to partition the underlying disk) and to use partitions as physical volumes.

Common tools as fdisk can not directly extend a partition size, rather they charge you to manully delete/recreate the partition; so online FAQs generally present you the simpler approach - to create a new partition and add it as a new physical volume. Moreover, in order to let the guest system to detect a partition extension, it is often required to reboot it. On the other hands, adding a partition pose no reboot requirement.

Anyway, I agree that continuously adding partitions in order to extend the vdisk size is not the best approach; I generally prefer to manually resize the partition (after taking a MBR backup) and reboot the guest system, then issue a pvresize against the resized partition.