On 7/27/2013 4:01 PM, Marcus Sorensen wrote:

Seekmark is very simple. It opens a block device with O_RDWR and
O_SYNC, divides the disk into block_size chunks, spawns a bunch of
threads, and each one chooses a random block, seeks there, writes,
then chooses another, seeks there, writes, etc.  There shouldn't be
any write barrier issue, since there's no filesystem involved. You can
also point it at a file on a filesystem and it will do the same with
that file, the O_SYNC *should* flush on every write.

There could be IO scheduler differences between the kernels.

~$ cat /sys/block/sda/queue/scheduler
[CFQ] noop deadline

Wes, yours will show CFQ probably as the default on RHEL/CentOS.  You'll
want deadline for best seek and all around performance.  So:

~$ echo deadline > /sys/block/sda/queue/scheduler

Add that to an init script or cron entry so it sets on every boot.

Also, make sure NCQ is working on each drive.  If it is, try disabling
it.  Look in dmesg for 4 lines like this with (depth 31/32), or at least
not zero for the first number.  Post the output for us to see.

ataX.00: xxxxxxxxx sectors, multi 16: LBA48 NCQ (depth 31/32)

quoted

quoted

Does seekmark use barriers

Barriers are not an issue with this test.

WARNING: never disable filesystem write barriers unless you have a
verified to be working battery/flash backed write cache hardware RAID
controller.  If you disable barriers with individual drives on SATA
controllers and the kernel crashes or you lose power, it can corrupt the
filesystem, sometimes beyond recovery.

-- 
Stan