(S)ATA performance in FBSD 6.2/7.0

Bruce Evans bde at zeta.org.au
Sat Mar 3 07:14:25 UTC 2007


On Fri, 2 Mar 2007, Brooks Davis wrote:

> Also, you should time the actual copy and do the math to verify that
> vmstat is actually producing valid results.  It's possible there's a bug
> in vmstat or the underlying statistics it uses.

There is certainly a bug in the underlying statistics.  For ATA disks,
at least with the ata driver, the maximum transfer size in DMA mode
is 64K, so any reports of a block size of 128K for SATA disks are
wrong.  The block size of 128K reported by vmstat is actually a virtual
size.  For most or types of disks, the GEOM layer virtualizes the
physical maximum size MAXPHYS = 128K so that layers above GEOM including
statistics gathering and file systems cannot see the physical size.
For writing large files, this normally confuses ffs and vfs clustering
into producing contiguous writes of 128K.  This is good for efficiency,
but it is not what the hardware sees or what you want for statistics.
The contiguous writes of 128K get split up into 2 sequential writes
of 64K.

However, 64K is more than large enough for efficiency, so the bug in
the underlying statistics doesn't matter, at least if vmstat reports
only 128K blocks.  If it reported 64K-blocks then you would have to
worry about the contiguous block sizes being a mixture of 128K and
much smaller blocks, with the much smaller blocks (actually, more
the seeks across gaps to get to the smaller blocks) being very
inefficient.

Bruce


More information about the freebsd-questions mailing list