Re: LVM write performance
On 8/19/2011 4:38 PM, Dion Kant wrote:
> I now think I understand the "strange" behaviour for block sizes not an
> integral multiple of 4096 bytes. (Of course you guys already knew the
> answer but just didn't want to make it easy for me to find the answer.)
>
> The newer disks today have a sector size of 4096 bytes. They may still
> be reporting 512 bytes, but this is to keep some ancient OS-es working.
>
> When a block write is not an integral of 4096 bytes, for example 512
> bytes, 4095 or 8191 bytes, the driver must first read the sector, modify
> it and finally write it back to the disk. This explains the bi and the
> increased number of interrupts.
>
> I did some Google searches but did not find much. Can someone confirm
> this hypothesis?
The read-modify-write performance penalty of unaligned partitions on the
"Advanced Format" drives (4KB native sectors) is a separate unrelated issue.
As I demonstrated earlier in this thread, the performance drop seen when
using dd with block sizes less than 4KB affects traditional 512B/sector
drives as well. If one has a misaligned partition on an Advanced Format
drive, one takes a double performance hit when dd bs is less than 4KB.
Again, everything in (x86) Linux is optimized around the 'magic' 4KB
size, including page size, filesystem block size, and LVM block size.
BTW, did you run your test with each of the elevators, as I recommended?
Do the following, testing dd after each change.
$ echo deadline > /sys/block/sdX/queue/scheduler
$ echo noop > /sys/block/sdX/queue/scheduler
$ echo cfq > /sys/block/sdX/queue/scheduler
Also, just for fun, and interesting results, increase your read_ahead_kb
from the default 128 to 512.
$ echo 512 > /sys/block/sdX/queue/read_ahead_kb
These changes are volatile so a reboot clears them in the event you're
unable to change them back to the defaults for any reason. This is
easily avoidable if you simply cat the files and write down the values
before changing them. After testing, echo the default values back in.
--
Stan
Reply to: