Re: striped LV and expected performance

On 19/7/25 04:08, Zdenek Kabelac wrote:
> Especially in virtual world you often get already some 'provisioned' spac=
e
> which nowhere near to anything physical. Try to stripe such drives makes
> no practical sense.

Been following this discussion with interest. I think the above sentence=20
sums up the entire discussion.

A few more things I want to add.

1. Adding controllers, even in a physical machine, with individual disks=20
and stripe across them is by far the worst thing you can do. As=20
controllers, especially the high end ones, do have a huge amount of=20
logic and knowledge of the underlying topology, it can, and will=20
optimise read and write operations to align with head positions and=20
other characteristics in case of HDD's. On SSD's it can/will align to=20
disk firmware settings and instructions. These are in 99% of all cases=20
not available in the OS as they will be masked by the controller. If you=20
add more controllers these will all operate independently and have no=20
insight in the IO pattern and can therefore only operate on a single io.=20
As there are then dependencies on different controllers and different=20
disks, all controls will need to come from the OS side.

2. Using guest IO controls. (Such as direct io parameters). These kind=20
of parameters will almost always be ignored by the underlying hypervisor=20
as that will by itself needs to determine the IO parameters in=20
conjunction with other io activity of other guests on that hypervisor.

3. Unreal cache optimisations. Using dd is by far the worst option to=20
use for performance tests as it will never (Ok, almost never) align with=20
real workloads. If you use dd for performance test you will find that=20
this will backfire in most cases when a normal workload is applied. The=20
main reason is that dd will always have a sequential workload unless you=20
start a large amount of dd instances to the same disk at once with=20
different offsets. Even then you will see an obscure number coming back.

4. Use a tool that can record and replay io workloads such as SWAT and=20
VDbench.

There are a massive amount of dependencies when it comes to storage=20
performance profile and optimisations. You may get really disappointing=20
outcomes when systems are configured with settings that come out of an=20
unrealistic profiling exercise and a real world workload will get=20
deployed on them.


cheers

Erwin