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