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

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to