You are adding a new data disk to a Linux server for LVM. Should you run pvcreate on the whole disk (/dev/sdb) or on a partition (/dev/sdb1), and what does each choice cost you?

## LVM is genuinely indifferent `pvcreate` accepts any block device: a whole disk, a partition, a multipath device, a hardware-RAID logical drive, a loop device. It writes an LVM label — by default into the second 512-byte sector, deliberately leaving sector 0 free so that a boot sector or partition table could coexist — followed by a metadata area holding the text description of the volume group. So the decision is not technical correctness. It is about what everything *else* on the system infers from the disk. ## The case for the whole disk **Nothing extra to manage.** One device, one PV. No partition table to create, no off-by-one about which partition is the right one. **Alignment is handled.** `pvcreate` aligns the start of the data area to 1 MiB by default, which sits correctly on every common physical sector size and RAID stripe. Hand-made partitions used to be the classic source of misaligned I/O; modern partitioning tools also default to 1 MiB, but with no partition there is nothing to get wrong. **Fewer layers when a virtual disk is enlarged.** When a hypervisor or cloud provider makes a virtual disk bigger, a whole-disk PV needs only LVM to be told the device changed size. A partitioned PV needs the partition table edited to extend the last partition first, which is an extra, more nervous step on a live system. **It reads as "this whole device is LVM's",** which is exactly true for a dedicated data disk. ## The case for a partition **It advertises itself.** A partition table with a Linux LVM type code (`8e` in MBR, GUID `E6D6D379-F507-44C2-A23C-238F2A3DF928` in GPT) tells every tool and every human that the space is claimed. A bare whole-disk PV shows nothing in `fdisk -l` beyond a note that the device does not contain a valid partition table — a phrase that has talked more than one engineer into initialising a disk that was very much in use. The type code is only a hint: LVM neither sets nor requires it, and `pvcreate` works fine on a partition of any type. Its value is entirely social. **It allows sharing.** If the disk must also carry an ESP, a `/boot` partition, or a non-LVM filesystem, you need a partition table by definition. Boot disks are therefore almost always partitioned. **Some firmware and tooling expects one.** Provisioning systems, imaging tools and certain hardware conventions assume a partition table exists. ## What actually decides it For a dedicated data disk on a server or VM, whole-disk PVs are a defensible and common default, and the fewer-layers argument makes them attractive in virtualised environments. For a boot disk, or any disk with mixed duties, partition it. Whichever you choose, apply it consistently across the fleet: the expensive failure is not either convention but a host where nobody can predict which one was used. ## The signature warning you will meet If the target device already carries a filesystem or an old LVM label, `pvcreate` notices and prints a warning naming the signature it found and the offset it found it at, then asks whether to wipe it. That prompt is a safety net worth reading rather than reflexively answering. Confirm the device is what you think it is — `lsblk`, `blkid`, `pvs`, and the disk's serial from `lsblk -o NAME,SIZE,SERIAL` — before wiping anything. When you are certain, `wipefs -a /dev/sdb` clears stale signatures explicitly, which is preferable to answering a prompt in a hurry because it makes the destructive act its own deliberate command. ## Making the disk hard to mistake Whichever layout you pick, a few habits reduce the chance of an accident: - Verify by serial or WWN, not by `/dev/sdX`. Kernel device names depend on discovery order and can move between boots; `lsblk -o NAME,SIZE,SERIAL,WWN` and the stable paths under `/dev/disk/by-id/` do not. - Check `pvs` and `lsblk` before touching anything. `lsblk` shows the LVM devices stacked on a disk, which is the fastest way to see that a device you thought was spare is holding a volume group. - Know that LVM has a device filter. `lvm.conf`'s `filter` and `global_filter` settings control which devices LVM will even look at, and current LVM versions additionally keep an explicit list of accepted devices managed with `lvmdevices`. If `pvs` does not show a PV you are certain exists, filtering is the first suspect. ## The part that is not a real difference Performance is identical. There is no measurable I/O penalty to either layout, and no partition-table overhead in the data path — the partition is just an offset. Anyone arguing the choice on throughput grounds is arguing about something that does not exist. The choice is about visibility, shareability and how many layers stand between you and the device when its size changes.