Re: striped LV and expected performance

On 25/7/25 00:10, Henry, Andrew wrote:
> Yes, me too, I've also been in the IT industry since 1992, and understand=
 product spec sheet theoretical maximums.
:-) Old-timers then... Hehehehe.....
>
> ""dd" will always give you a sequential read or write workload which will=
 always trigger optimisation functions in the various controllers and HDD/S=
SD firmware. The only thing it will show you is that your numbers will some=
what align to the numbers in the datasheet."
>
> Which is what I'm initially trying to validate, but not seeing.
I thought your first post started off running on a hypervisor. In that=20
case all bets are off and you're subject to what the host OS will allow=20
you to do. That puts a whole other pie in the mix.
>
> " Furthermore, reading from /dev/zero to push a workload will for sure sk=
ew numbers. The controllers are very smart and have been for a long time. I=
f they "see" a certain data characteristic they can change the write behavi=
our to the physical platter or the NAND cells."
>
> I had considered this, and if this was the case, wouldn't it give *better=
* performance?  If a DeDup identifies a pattern for instance, wouldn't I ge=
t *better* values in my tests than what the hardware was capable of?  In wh=
ich circumstance would I see worse numbers when controller logic kicked in?
One of the reasons could be that load-leveling logic in the SSD firmware=20
may cause delays, that's not something you can control. Also, if the=20
hypervisor does allow direct-io and the guest needs to wait for IO=20
completion or if the hypervisor has some settings applied that interfere=20
with IO completion, you will likely see skewed results. My experience is=20
that whenever you want to validate a specsheet you need to test this=20
under the same characteristics or you would need to be able to align=20
your IO profile that aligns to the specifications of the hardware. It=20
can be a massive time-waster if you can't automate the test-logic and=20
validate the outcomes to the datasheet numbers.
>
> /AH
>
>
> -----Original Message-----
> From: Erwin van Londen <[email protected]>
> Sent: 24 July 2025 15:57
> To: Henry, Andrew <[email protected]>; Zdenek Kabelac <zdenek.kabelac@g=
mail.com>; [email protected]
> Subject: Re: striped LV and expected performance
>
>
> Having worked in the storage industry since around 1995 with DEC, Compaq,=
 Hewlett Packard and Hitachi Data Systems (Vantara) I've seen a fair amount=
 of spec sheets. Be aware, what you see on these sheets are indeed optimum =
values measured against optimum characteristics for that piece of hardware.=
 These sheets are only partially written by engineers but will have a marke=
ting sauce added resulting in some potentially skewed information. Engineer=
ing information will most often outline the conditions of these numbers whe=
reas marketing people will most remove them as it simply looks better.
>
>   =C2=A0"dd" will always give you a sequential read or write workload whi=
ch will always trigger optimisation functions in the various controllers an=
d HDD/SSD firmware. The only thing it will show you is that your numbers wi=
ll somewhat align to the numbers in the datasheet. Various OS settings on t=
he scheduler, dm and filesystem can have a significant influence on these n=
umbers. I'm pretty sure that the information datasheets is about the maximu=
m you can suck out a piece of hardware.
> Everything you do on your side in the various OS layers will only negativ=
ely impact the raw performance numbers, let alone having a representative a=
pplication workload pushed onto it.
>
> "fio" gives you a bit more options and parameters however this will also =
depend significantly on how the kernel and it's IO layers such as the devic=
e mapper and filesystems interact with the hardware. Using zones for exampl=
e would require insight into the way the hardware is build, especially on H=
DD's. If you don't have that you may as well put a wet finger in the air an=
d go for a trial and error run.
>
> Furthermore, reading from /dev/zero to push a workload will for sure skew=
 numbers. The controllers are very smart and have been for a long time. If =
they "see" a certain data characteristic they can change the write behaviou=
r to the physical platter or the NAND cells.
>
> Everything you do that does not reflect a real life workload is a "just f=
or shits and giggles" exercise but will not give any real meaningful outcom=
e. Believe me, I've been through this discussion more than once.
>
>>
>>
>> -----Original Message-----
>> From: Erwin van Londen <[email protected]>
>> Sent: 21 July 2025 05:26
>> To: Zdenek Kabelac <[email protected]>; Henry, Andrew <andrew.hen=
[email protected]>; [email protected]
>> Subject: Re: striped LV and expected performance
>>
>>
>> 3. Unreal cache optimisations. Using dd is by far the worst option to us=
e for performance tests as it will never (Ok, almost never) align with real=
 workloads. If you use dd for performance test you will find that this will=
 backfire in most cases when a normal workload is applied. The main reason =
is that dd will always have a sequential workload unless you start a large =
amount of dd instances to the same disk at once with different offsets. Eve=
n then you will see an obscure number coming back.
>>
>