Anonymous
Unregistered | I'm pleased to read through the few posts regarding geom_raid5 here, and it seems like its time to "come home" and set up my next large-ish raid on FreeBSD instead of Linux.
I had just finished running a benchmark of Linux and MD v.s. FreeBSD and GVinum ... but this was a rather ugly for FreeBSD. Write speed was 25% of Linux, and read speeds were a bit better, but still only 50-70% of what Linux delivered. I also checked the speed of an individual drive to see if it was a driver issue on FreeBSD, but singe drive speeds were roughly the same.
So now I'm just writing this as I downloading the base sources, geom_raid5 and compiling the whole lot, and as I've slowly written two paragraphs graid5 is ready to go. I put it to a quick test on four small partitions and run bonnie on it. Wrtite performance is now on par with Linux, and read performance is just slightly lagging behind. But in all fairness this was a single run, with a single stripesize and default filsystem, and by the looks of it graid5 has a few tunables!
So, for the grand finale - will graid5 ever support online expansion (or offline for that matter)? |
Enlightenment
Administrator
 105 posts | | Posted on 25 June 2007 @ 23:14 | edited 23:27 |  |
Hello Anonymous (please register!  )
gvinum is a relic, the once popular vinum volume manager that was great in the times of FreeBSD 4, never really recovered from the geom area since FreeBSD 5. So unless you have good reasons to use gvinum you should use one of the geom modules instead, such as gconcat, gstripe, gmirror, graid3 and graid5.
geom_raid5 actually comes in two flavours; a stable release with conservative write back and a "TNG" release which with a good machine with plenty of RAM might reach speeds in excess of 400MB/s.
You need to tune your system for graid5 to run smoothly though. First, increase the kernel memory available to graid5. To do this, put this in your /boot/loader.conf (file may not exist yet):
# kmem
vm.kmem_size_max=410000000
vm.kmem_size=400000000
This assumes you have at the very least 512MB of RAM, probably you should have more.
Furthermore you might want to play with the sysctl variables:
kern.geom.raid5.maxmem=80000000
-> gives graid5 80MB memory hamster
kern.geom.raid5.maxwql=50
-> will store up to 50 write requests in a buffer
kern.geom.raid5.wdt=5
-> enables write-back mode and keeps requests for a maximum of 5 seconds
Also be sure to use a larger blocksize when using newfs. If you are creating a new UFS filesystem, use:
newfs -b 65536 /dev/raid5/volume
for example. Use -U option to enable soft-updates. Do NOT use a partition, like /dev/raid5/volumea. This will likely cause a misalignment.
I would be interested in the numbers you get and with what hardware you tested it with. Take control of the input and you shall become master of the output. |
Enlightenment
Administrator
105 posts | Also note that for kmem above 512MB you need to use 64-bit AMD64 platform version of FreeBSD. Take control of the input and you shall become master of the output. |
Anonymous
Unregistered | On the hardware side, I'm kinda in the toys department - all laptop components. 2.5" drives, Pentium-M CPU and 512MB RAM.
So far the performance has been peaking at about 80MB/s, FreeBSD and the stable branch was around 40MB/s i think, but it was all default settings. However NFS performance from FreeBSD was very poor (probably due to the Marvel driver or something). As soon as I'm finished moving house I'll try the TNG branch, these settings and a pro/1000 nic and see it it doesn't fix things!
Thanks for the pointers! |
Enlightenment
Administrator
105 posts | Ok sounds good! Hope to see your numbers then. Take control of the input and you shall become master of the output. |
Crafty
Unregistered | I'm doing benchmarking too, or at least would like to use them. But what program do i use? Bonnie is good? If not which one should i use? |
X00X
Unregistered | Benchmarking should be done to match your own use, and is not as easy as one might think. If you're unknowledgeable you'll end up having numbers that look either great or terrible but say little about your actual real-life performance.
Bonnie is a bad benchmark IMO. |
Enlightenment
Administrator
105 posts | Bonnie is not the best benchmark no, because it does not use cooldowns. But for quick'n'dirty benching it's pretty okay. But it does not test non-sequential performance which tends to be quite important. Take control of the input and you shall become master of the output. |
