> The last days I tried to figure out why some of my lab's FreeBSD boxes 
> and also mine at home seem to be outperformed by some Linux setups 
> around here and I saw something interesting.
> 
> 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!
> 
> In the first place I thought the older i386 hardware has some 
> hard-limits, but we have several boxes of the exact same hardware around 
> here and a wide spread Linux and Windows utilization and on those boxes 
>   equipted with more than one harddrive (PATA or SATA) the effective 
> transfer rate shown up is about 50 - 65 MB/s as expected with copying a 
> big 5G file from one drive to another.
> 
> The hardwrae limit is completely nonsense when it comes to the AMD64 box 
> with newer hardware.
> 
> Before digging into this problem deeper with benchmarks, could anyone 
> explain why FreeBSD reaches this 33 MB/s limit (sounds like UDMA 33 
> defaults, but on both boxes nForce4 and ICH5 controller are recognized 
> and show up with SATA300 or SATA150 capabilities, respective)? May I 
> have some knobs I'm not aware of to tune disk performance?
> 
> I would appreciate any coments on that and if someone has some good 
> ideas how to benchmark those subjects, please let me know.

I think you're quite OK with dd. I do believe you'll get a comparable results 
for cp setting "noatime" option in mount(8)s. As you were told, the default 
mount mode is noasync which is "synchronous metadata + asynchronous data". But 
FreeBSD still updates metadata for atime on every file read.

2all: Are there any reasons not to make noasync the default mount option? It 
greatly improves FS performance and I don't think many modern administrators do 
care about access times of their files (assuming how many files a modern box 
has).

Regards, Dmitriy.

_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to