(S)ATA performance in FBSD 6.2/7.0

Robert Watson rwatson at FreeBSD.org
Sun Mar 4 11:55:46 UTC 2007

On Fri, 2 Mar 2007, O. Hartmann wrote:

> On my lab's FreeBSD 6.2/i386 box (ASUS P4P800, ICH5 with two SATA 150 ports, 
> two SATA 300 drives attached) I copied big files (~ 5GB) from one drive to 
> another while the box didn't do anything else than copying. I watched the 
> copy process via 'systat -vmstat 1' and realized, that the value of 'KB/t' 
> never go byond 128 (128kb buffer limit?). But more frustrating, I never got 
> beyond 33 MB/s transfer rate although bonni/bonni++ told me both drives are 
> capable doing much more (~75 MB/s each). At home, I use a FreeBSD 
> 7.0-CURRENT box on an ASUS A8N32-SLI/nForce4-SLI based box, amd64 (no 32Bit 
> compatibility). Two Hitachi T7K250 250 GB/SATA II drives build up a RAID 0 
> (nVidia MediaShield), and additionally there is a SAMSUNG Spinpoitn SP2004C 
> attached to the controller. bonni results in 55 MB/s for the SP2004C alone 
> and gives ~ 65 - 70 MB/s for the Hitachis, each and roughly 115 MB/s for the 
> RAID 0. But copying from the single drive to the RAID 0 or from the RAID 0 
> to the single drive also reaches this oscure 33 MB/s boundary!

It would be helpful if you could provide the dmesg output for the ATA 
controllers and devices.  Sometimes, issues such as this come down to 
negotiated speed and bus topology.  For example, if you have two devices on 
the same bus, then each byte of data copied has to pass over the bus twice, 
which may run into performance limits on the bus where moving the data over 
the bus once won't.

Another area to investigate is the difference between raw device performance 
and file system performance.  Does it make a difference if you copy using dd 
to a file that is already allocated?  What performance does dd get when just 
reading from the file, or using dd to copy the file?  What if the file already 
exists and you are simply overwriting it (avoiding the overhead of 
allocating)?  Is your disk fragmented, leading to more seeks in placing new 
files, or is it relatively empty, which should lead to more contiguous 

Finally, disk performance varies enourmously by location where the I/O is 
taking place on the disk.  Try running diskinfo -t on your various disk 
devices, and see if there's a correlation between the maximum I/O rate you're 
experiencing and the location on the source or target drive?  On the ATA disk 
on my workstation, I see 53M/s on the outside of the disk platter, but only 
31M/s on the inside of the disk platter.  Especially if your drive is 
relatively full, files may be ending up in less preferred locations on the 
disk resulting in reduced performance.

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the freebsd-questions mailing list