Partitionless physical volume under LVM
I am wondering when will Red Hat going to decide to deprecate MBR & GPT disk partitions, use partitionless physical volume under LVM instead.
Responses
"backward compatibility" is something that everyone expects, dropping such a feature would not be that easy. I feel that if an operating system restricts user to partition less disks (for Pvs) then it is certainly limiting user choice.
You already can use partitionless disks with LVM. We do it quite frequently with AWS-hosted instances.
A few years ago, had a few VMware-hosted tenants do it with their RHEL6-based systems. Problem was, at the time, it could result in poorly-aligned volumes/filesystems. In turn, this created a lot more overhead on a given ESX-host if it was running poorly-aligned VMs at high consolidation-ratios.
How are you getting partitions misaligned? There's been quite a lot of effort put into having the storage layers aware of physical geometry and the tools automatically create partitions, volumes, and filesystems which align to the ideal geometry. If you have some condition where you can consistently produce a misaligned filesystem because that automatic detection fails, we'd appreciate a support case with those details. We could investigate that as a bug to improve the kernel/tools so that misalignment doesn't happen in the first place.
We also have the LVM RAID Calculator and Filesystem Layout Calculator to assist with these.
For resizing, we see a lot of customers just not resizing disks/partitions at all. Instead they add new block devices and expand the LVM onto those devices when they need more storage. I guess that depends on your specific needs and team. I'm sure we've all seen a SAN team who only allocate disks in fixed sizes.
I disagree that the concept of LVM on MBR/GPT partitions is irrelevant. There's always human error. I've worked many support cases where someone has seen a disk with no partitions and thought "that's not in use" so they've created a partition and filesystem and started writing data, only to later find their LVM volume is corrupt because they've overwritten the partitionless PV the LVM was using.
My recollection is that this was more a problem with RHEL 5 and 6 than it is with 7. The default starting-block for fdisk - when you didn't use expert mode - would start the partition at about the half-stripe point when you were using SAN-based storage. Most people running on physical hosts, workstations/laptops or VMs that didn't have high-demand disk I/o wouldn't notice the issue. However, if you were running, say, ESXi at high consolidation ratios, it could really degrade your VM host's storage-performance.
NetApp, for their part, used to publish an alignment-tool to help remediate systems that were mis-built on the default partition boundaries. I remember a couple months where our storage admins essentially forced the VM team to go back align the disks using that tool. We never did hear back from them with metrics showing that things were improved, though
At any rate, after that kind of mass-remediation exercise, you became acutely aware of the issues your storage team claimed. Armed with that knowledge, you simply knew "use expert mode and set a more-acceptable boundary". EL7 mostly got rid of the boundary by using a larger offset that better aligned with most SANs'/NASes' boundaries.
When you move to they type of block storage that's presented in cloud-storage environments, the alignment issue typically vanishes (either that or the storage admins have bigger fish to fry). In those environments, the primary reasons for continuing to partition are, as you note, avoiding the whole, "oh, here's a free disk" problem. That said, in those cloud environments, use of partitioning and LVM is typically discouraged altogether. Indeed, the primary thing that continues to drive the use of LVM is some enterprises' security teams insisting on specific storage-slicing schemes (see DISA's STIGs for an example).
With more up to date kernels, the dynamic geometry change problems tend to be greatly reduced. With RHEL's move to XFS as the default FStype, most people aren't going to be shrinking filesystems, any way, so the need for LVM to facilitate that use-case is vastly reduced. And you never needed LVM just to grow an ext3/4 partition. If you're using storage subsystems that support on-the-fly LUN-resizing, the value of LVM to support expanding storage is of low value - particularly if you're running either partitionless or 1-disk:1-partition schemes (in which context, the kernel's ability to dynamically accept geometry changes is your primary inhibitor).
I always advocate (and still do) using partitions on the disk (LVM, type 8e) and adding the partition as a PV to LVM. This avoids the disk being picked up by other tools or overwritten accidently by other administrators when they are adding disks or carrying out maintenance etc (I have seen and assisted in recovery from this many times). If only to 'mark' the disk as used, I find using partitions valuable and the only argument I have seen against this is from administrrators that resize their disks. I also place a partition on ASM disks for similar reasons.. gasp from the crowd
I also prefer to add disks to PV and expand the VG rather than resizing disks (as Jamie has mentioned), this has never caused any issue. There is a similar reason for this preference.. adding/carving new LUNS from the storage system is 'safer'. Having a storage admin playing around with the existing storage geometries to resize disks/LUNs can result in painful mistakes.
I don't see what motivation or benefit Red Hat would have to deprecate this capability just because some administrators prefer a different approach?
As mentioned by others you can use the entire disk (e.g. /dev/sdg) as the PV instead of having to create a single partitiong (e.g. /dev/sdg1) to use as PV. Early on we did the latter but we quit doing that years ago on RHEL5 and don't do it on RHEL6 or RHEL7 when presenting SAN storage or even secondary LUNs from internal RAID cards like Dell PERC (or LSI which became Avago). We DO partition the first LUN from internal RAID because we want the boot device to be on partition so for that we'll create sda1 for /boot then sda2 will be a PV for LVM.
As Jeffrey said, on boot devices a partition table or some other hardware-architecture-specific structure is required to allow the system to boot, as the firmware will use these structures to find and load the primary bootloader code. So the deprecation of MBR & GPT is not in RedHat's hands, but controlled by the hardware/firmware producers.
For example:
on x86 hardware with a traditional BIOS firmware, the system expects a valid MBR with a boot code, although the BIOS may or may not check for MBR partitions marked as bootable.
on x86_64 and Itanium hardware with an EFI/UEFI firmware, the firmware expects a GPT partition table, and an ESP partition that includes the bootloader as a file on a filesystem (the ESP filesystem type may be essentially FAT32, or optionally another filesystem type for which the system manufacturer has included a filesystem driver in the firmware.)
on HP-UX PA_RISC (now legacy), the firmware expects the bootloader to be contained in a LIF volume located at the beginning of the disk, outside LVM-managed area
on Solaris SPARC, the firmware expects a VTOC disklabel (= a type of partition table) that includes information of the location and length of the bootloader code.
On non-boot disks, Linux systems leave the decision to partition or not to the sysadmins, as the best approach is dependent on site-specific details. For example, a site that uses all-Linux systems and local RAID controllers could easily and without risks use whole-disk PVs. On the other hand, a site using both e.g. Windows and Linux systems in a shared SAN storage system might want to use partition tables on all LUNs just to maximize the chance that a specific configuration error (accidentally presenting a LUN that's already in use to another system) will be caught before the LUN is overwritten.
(I've seen what happens when a SAN LUN that is used as a whole-disk HP-UX LVM PV gets presented to and used in a Linux system. The results were... not pretty. In that case, partitioning would not have helped as Linux does not really recognize HP-UX LVM, and HP-UX won't recognize MBR partition tables without extra tools.)
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
