mgb
Member
3 posts | Hello enlightenment et.al.
I have a problem I hope you can help me with.
First of all
I have been doing some surfing and found a
geom_raid5, geom_raid5-eff and geom_raid5-pp
release of geom_raid5.
Wich one should I choose. so that it will most likely be compatible with what ever gets into the freebsd source-tree at some point?
Could I use -pp now but later go 'back' to -eff or just plain geom_raid5, or are they in compatible?
I have 4 1Tb disk where one holds all my content as we speak
I would like to at these to a 4 disk raid5.
But I have to do this in two steps.
first wit 3 disk and then copy the content from the 4 and then extent the setup with the 4th disk. Now I have read elsewhere that you are developing a tool that could aid me there.
So I was wondering if I could have a copy to play around with 
I understand that this is beta to say the least, but I am fine with being your test subject if you will let me
Any other thoughts on my future setup would also be much appreciated
TIA
mgb |
Enlightenment
Administrator
 104 posts | | Posted on 26 April 2008 @ 15:19 | edited 15:21 |  |
The three geom_raid5 versions are upwards compatible, meaning you can go from classic to TNG/eff, and from TNG/eff to PP, but not backwards. FreeNAS still uses the classic version, but Olivier will probably start to use PP in the future. He already wrote me about that.
I can suggest using PP, you may which to tune the kern.geom.raid5.cs value, the Cache Size. A too high value may cause kernel memory shortage. Be sure to set your kernel memory to a decent value (preferably 300MB or so). The memory usage also depends on the number of disks and the stripe size used. The higher these two, the higher the memory usage. High memory usage can very well mean higher performance, since storage is often a bottleneck causing the CPU et al to idle, waiting for the relevant data to arrive from the relatively extremely slow storage device, which is inherent for any mechanical storage device.
My expansion script could indeed allow you to circumvent making a backup and migrate from a single disk to a 4-disk RAID5, as you wrote. But doing so is far too dangerous with the current state of the script; you should not attempt to use the script on REAL data unless you have a 100% solid backup. But, there is another option:
1) Create a 4-disk RAID5 array using the 3 remaining disks and 1 'virtual' disk using gvirstor virtual storage module.
2) Rightly after creating the array, remove the virtual disk so you array is running DEGRADED.
3) Copy the contents of your single disk to the degraded RAID5 array.
4) Once complete, unmount the single disk and attach it to the array. The contents of the single disk will be overwritten by parity data and the array will soon be in COMPLETE state.
The result is a 4-disk RAID5 array with your data on it. If properly done, the risk with this operation should be minimal.
Hope this helps. Take control of the input and you shall become master of the output. |
