In LVM on Linux, what is a physical extent (PE), what extent size does vgcreate use by default, and what does that choice actually affect?

## The unit LVM actually thinks in LVM does not track byte ranges. When a volume group is created, each of its physical volumes is carved into equal-sized **physical extents** (PEs), and every allocation decision after that is "which extents, from which PV". A logical volume's on-disk definition is essentially a mapping from its own logical extents (LEs) to physical extents on named PVs. Logical extents are the same size as physical extents in the group, so the two counts line up one-to-one for a simple linear volume. That design is why LVM operations are cheap. Growing a volume is appending extents to a list and reloading a device-mapper table; nothing is copied. ## The default, and how to change it LVM2 uses **4 MiB** extents by default. You set a different size at group-creation time: ```bash vgcreate -s 16M vg0 /dev/sdb /dev/sdc vgdisplay vg0 | grep 'PE Size' ``` The size must be a power of two and at least 1 KiB. It is a property of the **volume group**: every PV that joins the group is divided using the same size, so you cannot mix 4 MiB and 16 MiB extents inside one VG. ## What the choice actually affects Three things, in descending order of how often they matter: **Granularity.** Extent size is the quantum of every size you can ask for. With 4 MiB extents an LV's size is always a multiple of 4 MiB; with 128 MiB extents you cannot create a 100 MiB volume at all — you get 128 MiB. On a group hosting many small volumes, a coarse extent size silently inflates every one of them. **Metadata and operation cost.** Each extent is an entry LVM has to account for. A 100 TiB group with 4 MiB extents is roughly 26 million extents; the metadata gets large and allocation and reporting commands get slower. Bumping the extent size to 32 MiB or 64 MiB on very large groups is the standard reason to deviate from the default. **Nothing about performance.** This is the common misconception. Extent size is an allocation granularity, not an I/O size. It does not set a stripe width, a chunk size or a readahead value; a filesystem doing 4 KiB writes does 4 KiB writes regardless of whether the extents beneath it are 4 MiB or 64 MiB. (The one place a size *does* affect I/O layout is the stripe size chosen when creating a striped LV, which is a separate parameter entirely.) ## The rounding you will actually see ```bash # 4 MiB extents; 10 MiB is 2.5 extents, so LVM takes 3 lvcreate -L 10M -n test vg0 # Rounding up size to full physical extent 12.00 MiB ``` LVM rounds **up**, never down, and it tells you when it does. This trips people who script size arithmetic and then assert on an exact byte count afterwards. When you want to be exact, ask in extents rather than bytes. `-l` accepts a raw count or a percentage expression: ```bash lvcreate -l 2560 -n test vg0 # exactly 2560 extents lvcreate -l 100%FREE -n data vg0 # every unallocated extent in the VG lvcreate -l 50%VG -n half vg0 # half the group's total size ``` `100%FREE` is the idiomatic way to consume the remainder of a group without doing the division yourself. ## Reading the extent numbers `vgdisplay` is the clearest view: it prints `PE Size`, `Total PE`, `Alloc PE / Size` and `Free PE / Size`. The compact commands expose the same figures as columns — `vgs -o vg_name,vg_extent_size,vg_extent_count,vg_free_count`, and `pvs -o pv_name,pv_pe_count,pv_pe_alloc_count` per disk. `lvdisplay -m` goes one level further and prints the segment map: for each range of logical extents, which PV and which physical extent range backs it. That segment map is the practical payoff of understanding extents. It is how you answer questions like "is this volume actually spread across both disks, or did it all land on the first one" — which is not visible from `lvs` alone. ## A note on capacity you cannot use A PV whose size is not a whole multiple of the extent size loses the remainder: the leftover tail is smaller than one extent, so nothing can be allocated from it. With 4 MiB extents that is a rounding error. With a deliberately huge extent size on many small disks it can add up, which is one more reason not to raise the default without a concrete reason.