LVM / Linux block storage
One workload, two layouts, one race.
A linear logical volume sends a stream to one physical volume at a time. A striped one cuts the same stream into fixed units and hands them to several PVs at once. Run both on identical hardware and watch where the bottleneck moves.
Same workload, both layouts, at the same time
Both lanes receive an identical I/O stream. The columns are the eight physical volumes; each moving block is an I/O landing on one of them.
-i 8 -I 256
Throughput
0.00GB/s
Active PVs
0/ 8
Response time
—
Elapsed (modeled)
—
Throughput over time
Throughput
0.00GB/s
Active PVs
0/ 8
Response time
—
Elapsed (modeled)
—
Throughput over time
Interactive comparison of linear and striped LVM logical volumes running an identical workload across eight physical volumes.
Where the blocks actually go
The same logical address space, mapped two ways, at the geometry used in the race: eight legs, a 256K stripe unit.
Whole logical volume — capacity distribution
How much of each PV the LV consumes. Linear fills PVs in order; striped spreads evenly across its legs.
First 4 MB of the logical volume — stripe units
Zoomed to the stripe unit. Each cell is one unit of the logical address space, coloured by the PV that holds it.
When striping does nothing for you
The race uses 1 MB writes, where striping pays off. It does not always. Parallelism inside a single request only happens when that request is larger than the stripe unit — drag the block size and watch how many PVs one I/O actually touches.
PVs touched per I/O
4 / 8
Single-stream ceiling
3.00 GB/s
Why
The commands behind each layout
Identical hardware, identical filesystem, identical benchmark. One flag pair is the whole difference.
Side by side
Measured with vdbench on the lab rig. Switch the workload in the race controls to see the other set.
| Metric | Linear | Striped | Delta |
|---|
Reach for linear when
- You are adding capacity, not chasing throughput.
- PVs are different sizes, or you will grow the VG with whatever disks arrive.
- The workload is many independent small requests — concurrency already spreads the load.
- You want the simplest possible extension path:
lvextendand go.
Reach for striped when
- A single stream has to go fast — backups, restores, bulk loads, scans.
- Your I/O size is comfortably larger than the stripe unit.
- PVs are equal in size and sit behind equal paths.
- You can accept that growing the LV means adding PVs in multiples of the stripe count.
How the numbers work. The throughput and response times in the race and the results table are measured vdbench results from the lab, at -i 8 -I 256. The ceilings in section 03 are modeled from that same baseline: 1.5 GB/s per physical volume and a 3.0 GB/s path ceiling, which is the limit of the connection in front of the array rather than of the disks behind it.
Two honest caveats. Linear does not mean "one disk forever" — a 500 GB LV lands on five PVs, and concurrent random readers hit all five at once, which is why linear closes most of the gap on small random I/O. And striping does not accelerate a single 4 KB read: that request lands on one PV either way. What striping buys on random workloads is an even spread of queueing, not parallelism inside the request.