Re: striped LV and expected performance
Zdenek Kabelac <[email protected]> Fri, 18 Jul 2025 20:08:57 +0200
| Newsgroups | gmane.linux.lvm.general |
|---|---|
| Message-ID | <[email protected]> |
Dne 18. 07. 25 v 16:46 Henry, Andrew napsal(a): > Dne 18. 07. 25 v 14:24 Henry, Andrew napsal(a): >>> Maybe you virtual system does have it self 'a single write pipe' - so any parallelization is stopped right there - so maybe you should start first with bare metal.... >> >> This is what I suspect is happening, as the back-end storage is very fast. I'm going to test on a physical server instead. >> >> /AH > > It's crucially important to be sure - you have independent drives & controller paths to them. > > It's really pointless trying to setup a 'stripe' on top of 3 drives that are at the end served by a singly physical storage behind the scene - this likely can explain rather horrible numbers you get when you are trying to use stripe > - in such case simply join devices 1-by-1.... > > Zdenek > > I re-tested this on a consumer PC. > > SATA6 controller, 2 * 1TB Seagate 4ke drives with product spec of ~210MB/s read speed and ~160MB/s write speed. > > Created the lv as follows: > > Plus all these results are sort of inline with the physical characteristics of the drives max R/W speeds. > > When I perform same procedure on a VM using the paravirtualised driver for the 3 controllers, I'm not getting speeds in-line with what I expect from solid state storage. Obviously, striped LVM in a VM with storage pool connected to the VM host just does not work the way it would with separate physical devices. So the short answer here can be - never try to 'stripe' anything you don't have direct hardware knowledge & control. Especially in virtual world you often get already some 'provisioned' space which nowhere near to anything physical. Try to stripe such drives makes no practical sense. Regard Zdenek