Below is a GNUPlot graph of ZCAV output from a 250G SATA disk. The disk has something wrong with it (other disks of the same brand in machines of the same configuration give more regular graphs). The expected graph will start high on the Y scale (MB/s) and steadily drop as the reads go to shorter tracks near the spindle. The ZCAV results page has some examples of the expected results.
If you have any ideas as to what might cause this performance result then please make a comment on this blog post.
Update: This problem is solved, I’ve written a new post explaining the answer. It’s a pity that an NDA delayed my publication of this information.
Hi Russell,
I read your blog via planet.debian.org. I saw this post a while back and can only offer a suggestion for the pattern you’re seeing: that the linear distance of the disk head to the spindle is out of phase with the memory address it’s reading. That will cause the phaselike pattern in the data. I think that the Head/Cylinder/Sector count (if applicable) or some stage in the driver layers is getting confused as to the actual data layout on the disk. That’s my guess as a mathematician with hobbyist interest in computers and no experience of the bare metal of hardware drivers. It seems reasonable to me, attribute it to a bug in libata…
Take care.
Ken.
libata has no control over the sector placement, it’s all in the disk.
Disks will remap sectors when there are errors, but it seems quite unlikely that so many sectors would be remapped without an IO error that’s visible to the user.
Also the disks in question perform better when installed in different machines. One theory that is being investigated is that vibration is part of the cause.
If the IO wasn’t contiguous and if the disk wasn’t smart enough to do read-ahead then I might consider the possibility of sequential reads being delayed long enough for the disk to need an extra rotation. But I don’t think that’s the case.
I would guess that the problems are
zcav reads chunks of data assuming 512byte sectors – many disks actually don’t keep data in sectors like that
zcav assumes that you can know the cylinder/head/sector mapping – this is pretty much only known to the disk manufacturer
Paul: Disks store data in units of >512 bytes, it’s 512 bytes plus some ECC.
http://www.coker.com.au/bonnie++/zcav/results.html
If you visit my main zcav results page (above URL) then you’ll see what it should look like (and does look like on a variety of types of disk).
ZCAV assumes nothing about the cylinder/head/sector mapping. The reason I wrote it is to discover a basic summary of such data experimentally.