Fellow humans! If you install Rockstor on mission critical servers, you may want to create a two drive mirror for the OS. I’ve written up a descriptive howto with pictures on how to set that up and recover from a drive failure. Here it is in the howto section of documentation.
I think 45Drives already ship with this setup if you get a box from them. @bkelly, feel free to suggest any improvements to the doc!
Hello Suman,
can you explain, why you chose mdadm over btrfs for the boot-drive?
Besides this: Isn’t 1GB for /boot a bit much? I would have chosen less then a quater.
Last but not least: I would like to have this setup:
Devices: a) 16GB SSD, b) 128GB SSD
I would like to combine the first 16GB of b) with a) to the boot drive and use the rest for RockOns.
I think, this should be possible, but unfortunately, a) is still in use by the predecessor of Rockstor, until I have Rockstor up and running with all I need.
Is it possible to install on a ‘degraded’ or incomplete raid?
Greetings,
Hendrik
Ideally I’d like one btrfs pool in raid 1 on two drives of equal size. Last time I checked, there is a grub tweak that makes this setup not quite ready. It may have changed by now. So hopefully soon. In such setup, / and /boot would be sub volumes and every version update would nicely be snapshotted. We’ll get to this, hopefully soon but if you or anyone else get this working before us, please share the steps.
Given our frequent kernel updates, 1gb is a safe size for now.
Hello Suman,
can you point me at that grub tweak you are referring to?
Regards,
Hendrik
Hello,
Coming back on this:
Last but not least: I would like to have this setup:
Devices: a) 16GB SSD, b) 128GB SSD
I would like to combine the first 16GB of b) with a) to the boot drive and use the rest for RockOns.
I think, this should be possible, but unfortunately, a) is still in use by the predecessor of Rockstor, until I have Rockstor up and running with all I need.
What I intended to do now is:
-Install on drive a) and select BTRFS as the OS
-Manually partition b) add the first 16GB to the root pool manually and then use rest and use it for Rock-Ons.
Unfortunately, I think there is no way using the rest (so the second partition of b) in Rockstor. Is there?
Greetings,
Hendrik
Hello,
I have raised this issue in the BTRFS Mailing List at http://www.spinics.net/lists/linux-btrfs/msg51631.html .
The experts there are very supportive, but I am stuggeling to answer some of the questions.
@suman: Would you mind joining the discussion? You do not need to join the mailing list. You can directly post to the list (linux-btrfsATvger.kernel.org)
Regards,
Hendrik
Hello,
I got the feedback in the mailing list above that this behaviour is not visible in Centos 7.2.
So, this raises two questions:
a) is Rockstor really based on 7.2
b) what modifications are made -probably to the initramfs- that could trigger the problematic behavior?
@suman: It would be good if you could support here. People in the btrfs mailing list are very supportive and I think we could fix this issue soon.
Greetings,
Hendrik
I’d like to look at this soon, thanks for your research so far. Rockstor is based on latest CentOS packages, so yes, 7.2. No modifications are made to initramfs.
I have a question for you, are you able to setup the btrfs mirror on vanilla CentOS 7.2? If so, please do share detailed steps. That can be really useful.
Hello,
I have not tried myself, but Chris Murphy did post this:,
- Install CentOS 7.0 to vda
- reboot
- btrfs dev add /dev/vdb /
- reboot
works- btrfs balance start /
- reboot
works
Same thing when starting with CentOS 7.2 media.
This is a NAS product using CentOS 7.2? My only guess is they’ve
changed something broke this.
I think it’s a good opportunity now for you to join the discussion in the mailing list. Chris is really knowledgable wrt. btrfs and he has already looked into this problem. Let’s try to find out why it is not working for rockstor.
Greetings,
Hendrik
Hello Suman,
don’t you think so?
Greetings,
Hendrik
Yes it would be great to improve the installation process in order to avoid these steps http://rockstor.com/docs/mdraid-mirror/boot_drive_howto.html
I could help with testing.
Regards,
Augusto
So I went through this guide with 2x Intel 120GB SSD.
I use the following;
/boot 4GB
swap 8GB
/ 100GB (remainder)
When I come to the recovery process, mkfs, then reboot into the installer again, I can setup the /boot and swap, but / only allocates 8GB of the 100GB capacity. Also, you need to update the documentation at this step as it defaults to LVM, and you need to change that to BTRFS.
In any case, it does not allow me then to make /home as it says there is no space available.
So I end up with / at 8GB mount point (sub volume) but no /home and still, in theory heaps of spare capacity that is unused.
I tried the entire process 3 times and always looks the same.
This looks like a bug to me.
I have now proceeded with the installation and it boots and comes up.
How can I fix it live to extend the / over the entire volume?
How can I add /home?
Is the 8GB it allocated sufficient?
EDIT: I think it didn’t work properly, it seems like it used the space from one drive, the swap, as I did not mdraid the swap, as per the instructions.
so it wouldn’t create / on the BTRFS mdraid volume.
Not sure where this is going wrong???
I follow the instructions to the letter.
Maybe I need to mdraid swap too?
EDIT 2:
A small innocuous thing I forgot. It could be because I left my glasses at work 
Need to select “Select btrfs for the partitioning scheme (centre left)”, I didn’t notice this and didn’t think it would be needed, since we went through the process of making the BTRFS mdraid volume to start. I was also surprised that this option disappears when you start creating the volumes, so can only be changed at the start. Also surprised it isn’t set to BTRFS by default at the beginning.
Seems to all be working now. Good job on the guide. Can you highlight the option I missed so others don’t make the same silly mistake 
@GIDDION Thanks for yet another helpful post. Yes it was quite a job to persuade our almost unmodified upstream Anakonda installer to get the results we were after. Hence the double install procedure and strange defaults etc. Hopefully as btrfs, grubby, grub, et al develop we can move to a more btrfs native arrangement raid wise on our system disk. But in the mean time this does appear to work, all be it in a rather long winded double take type fashion.
@Spectre694 in the following forum thread seems to have gotten to the nub of the current upstream holdup on this:
As per your suggestion I have opened a new issue in the rockstor-doc repo with your exact recommendation:
Thanks for your diligence on this one and glad you got there in the end.
Great, I confirm it’s working now. The Doc http://rockstor.com/docs/mdraid-mirror/boot_drive_howto.html now seems Ok.
Thanks
@GIDDION Just to let you know that the issue opened as a result of you docs suggestion has now been closed as the indicated ‘pivotal’ step now has a big IMPORTANT next to it.
@augusto.b Thanks for the additional proof on this howto.
better, but… there is always a but…
Can you make it RED?
I know this sounds silly, but I wouldnt say that I am a novice, nor would I say I am an expert, it is very easy to overlook these points, grey, even though in CAPITALS, doesn’t really jump out at you.
@GIDDION Thanks for the additional feedback; I did neglect to say that it is a bold capitalised IMPORTANT and given every other step in the howto is also equally important we are verging on an inconsistent presentation as is. I think what made your original point valid, in my opinion, is that there is a user expectation to not have to do this step again, as you pointed out, and this is a very unusual install process where we are rather going against the installers defaults but it does server to address advanced users requirements but is far from an ideal arrangement. Also this particular step is uniquely ‘hidden’ right under a title and so on a quick look could be over looked, hence the action taken thus far on your recommendation. Care was taken to provide either images of the required steps and/or bullet list indicators and this particular howto has taken quite some time to develop both from @suman and myself and although I definitely think your initial suggestion has improved things I personally don’t think further highlighting of this step would contribute any further. After all there is also an image to indicate the expected outcome. So in the vein of guiding the docs development I would like to respectfully decline my support of this further customisation. Also note that adding colour to this type of doc (rst) does rather increase it’s formatting complexity as we have to inject additional roles or raw html which I would like to keep to a minimum. I may be overruled on this, and in which case so be it, but I definitely think you have helped to improved this doc thus far.
So for the time being I hope you are not offended if we put this red formatting idea by the way side for the time being as the closer we stick to basic formatting the easier it is for document contributors to contribute consistently and I also don’t think that additional emphasis on this one step is of any more utility.
I hope you feel like I have made my point fairly on this one and do keep in mind that I am regularly wrong and know it but I think it’s as important to reject ideas as to enact upon them, which in this case I find is my ‘current’ opinion.
Thanks for taking such an active interest in the docs by the way. I think there is still much to be done on them; particularly in the realm of consistency (ie docs on connecting to shares) so hopefully with the increasing activity in the community in this area we are moving in generally the right direction.
I do have scheduled in a more significant stint on the docs but I fist have some support on recent changes that are ‘my fault’ to tend to plus a fairly major stint on unit testing, then a stint on adding full disk encryption; but there after is my planned docs stint and part of that will be re-visiting this howto so maybe by then I will see things your way .
Oh and as far as I’m concerned there is nothing too small / silly to be discussed in the forum as otherwise I would have little to contribute myself. And I think worrying the details can, in some instances, make all the difference.
Cheers.
Never offended, I appreciate your feedback and taking the time to respond. All good, bro.
Keep up the good work.