When creating an LVM logical volume with lvcreate, what is the difference between the default linear layout and a striped one requested with -i, and when does striping actually buy you anything?

## Two ways to lay a volume across a pool A logical volume is a list of extents, and the interesting question is *which* physical volumes those extents come from and in what order. LVM's segment type answers it. **Linear** (the default) is concatenation. The allocator takes extents from a PV until it runs out, then moves to the next. A 300 GiB volume across two 200 GiB disks is 200 GiB of disk one followed by 100 GiB of disk two. Logical block 0 and logical block 1 are adjacent on the same device, so any individual read or write is served by exactly one disk. **Striped** interleaves. With two stripes and a 64 KiB stripe size, the first 64 KiB of the volume live on PV A, the next 64 KiB on PV B, the next on A again, and so on. A single 1 MiB read is therefore chopped into requests against both devices, which issue them concurrently. ```bash lvcreate -L 100G -n data vg0 # linear, the default lvcreate -i 2 -I 128 -L 100G -n fast vg0 # 2 stripes, 128 KiB stripe size ``` `-i` is the stripe count; `-I` is the stripe size in kibibytes (the default on current LVM2 is 64 KiB, and it must be a power of two). ## What striping actually costs and requires **You need the disks.** With the default allocation policy, LVM places each stripe on a different physical volume, so `-i 3` in a group containing two PVs fails outright with an insufficient-allocatable-extents error. This is not a bug — a stripe set built from two ranges of one disk gives you the seek pattern of striping with none of the parallelism. **The layout is baked in.** The stripe count and size become part of the volume's segment definition. They are not a runtime tunable you can revisit later, so choose them when you create the volume. **Space is consumed in lockstep.** A striped volume takes an equal number of extents from each PV it stripes over, so the usable size is bounded by the smallest contributing disk. Ten spare gigabytes on one PV and none on another is unusable for a two-way stripe. **There is still no redundancy.** Neither layout protects anything. The difference is the blast radius when a PV dies: with a linear volume, files whose extents happened to land on the surviving disk may be recoverable; with a stripe, every file of any size has a piece on the dead device. Striping makes an unprotected volume *more* fragile in practice, which is why it belongs on top of already-redundant devices, not instead of them. ## When it helps — and when it is theatre Striping only wins where the bottleneck is per-device and the devices are genuinely independent: - Several separate physical disks or several separate NVMe namespaces, with a workload doing large sequential I/O or deep parallel I/O. Throughput adds up close to linearly. - A database or log volume where per-device queue depth is the limit rather than the fabric behind it. It does nothing useful when: - The PVs are partitions of the *same* physical device. You have added seek work and gained no parallelism. - The PVs are LUNs carved from one SAN pool or one hardware RAID set. That array already stripes across its own members; layering another stripe on top mostly changes request sizes. - The workload is small random I/O. Each request is smaller than the stripe size, so it lands on one device anyway; the gain comes from having more devices in the group, which linear allocation across a busy pool also delivers. On cloud block storage the calculus is different again: throughput is usually capped per volume by the provider, so attaching several volumes and striping over them is a legitimate way to buy more of it — but the limiting number to check is the instance's aggregate storage bandwidth, not the disk's. ## Telling what you have Existing volumes reveal their layout: ```bash lvs -o lv_name,vg_name,seg_type,stripes,stripe_size lvdisplay -m /dev/vg0/data ``` `seg_type` reads `linear` or `striped`; `stripes` is the count. `lvdisplay -m` prints the segment map — for each range of logical extents, the type and the physical volumes backing it. A volume can even be a mixture: segments created at different times can have different types, which the segment map makes visible and the summary line does not. ## The honest default For most general-purpose volumes, linear is the right answer. It imposes no constraints on how space is consumed, it lets a volume grow onto whatever PV happens to have room, and on modern storage the parallelism it supposedly gives up is usually being provided a layer down. Reach for `-i` when you can name the independent devices you are spreading across and the workload whose profile makes the difference measurable — and when the data underneath is protected by something other than hope.