[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (S)ATA performance in FBSD 6.2/7.0



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 storage?

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
_______________________________________________
freebsd-performance_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe_(_at_)_freebsd_(_dot_)_org"