In the last read tests I found that the sequential read IOPS have been higher than expected. I left “invalidate” on default, that means that the used file for the test should be dropped out of the page cache when the test starts. So why are the IOPS higher then the raw device performance? I found that the readahead is responsible for this.

Important: readahead will only come into the play when the read is using the page cache. This means “direct=0”.

Set and get the readahead value

You can use the tool “blockdev” to show the readahead value:

1

sudo blockdev--getra/dev/sda1

or set the size with:

1

sudo blockdev--setra128/dev/sda1

Example with different readahead values:

I set the readahead value to 128 and run this file: readahead

1

2

3

4

5

6

7

[readahead]

rw=read

ioengine=sync

direct=0

invalidate=1

size=100MB

filename=/840/testfile1;ThisisSamsung EVO840with ext4 defaults

“issued: total=r=25600” shows that 25600 IOPS have been issued but “sda : ios=561” shows that only 561 hit the device.So we can estimate that to read 100MB with 561 IOPS each IOPS needs to be ~182KB. This seems to be higher then 128 (read ahead value) * 512Bytes (default sector size) = 64KB. Something is wrong! I run:

1

sudo blockdev--getbsz/dev/sda1

With an output of 4096. Okay the physical block size is 4096 Bytes and not 512 Bytes. 128 (read ahead value) * 4096 Bytes (physical block sector size) = 256KB. This would fit much better with the value of ~182KB.

I set the readahead value to 256 and run the same test again.

296 IOPS means around the half of the IOPS than the last test.

I set the readahead value to 512 and run the same test again.

Again around the half.

So this value can have an impact on the sequential read performance of your device. But most of the times sequential read are not the bottleneck in a typical environment. Even HDD’s can provide really fast sequential reads as long the fragmentation is under control.