Clarification Re pools for rock-ons

Support
1

[Please complete the below template with details of the problem reported on your Web-UI. Be as detailed as possible. Community members, including developers, shall try and help. Thanks for your time in reporting this issue! We recommend purchasing commercial support for expedited support directly from the developers.]

Brief description of the problem

[ Hi
Been researching in and around Rockstor now for a couple of months, utilised an old PC (Celeron core duo on an ATX MOBO), waited for Black Friday deals (Ebay) and purchased 4X2Gb Ram, a Kingston A400 240 Gb SSD (OS), a couple of Seagate Ironwolf 4TB HDD (Data Store), plus some accessories from a local supplier.

Downloaded the generic ISO and utilising the recommended ISO builder (Rawrite 32 disc image tool) for a USB device installation which ran very neatly. (I had more problems changing the boot sequence in the BIOS being an absolute novice).

So, Rockstore is up and running with very little pain, not being used to anything outside of windows for a lot of years (Before windows 3.1) I stumbled at the change over from a monitor to a WEB UI, waiting for a screen to open, wondering what should happen next until I noticed a note re the web address to access the system. (Felt a bit daft at that moment).

Anyway, I am now setting things up whilst heat soaking the new (and old) kit (Is that still a term/process used?) and have got to the stage of setting up pools and shares.

From my interpretation of the docs a pool is usually a whole disc or set of discs
Quoting from the docs
“ Creating a Pool
Only whole disk drives can be used to create Pools
When reading about setting up rock-ons I find:

The Rock-ons root

All Rock-ons require the Rock-on service to be enabled and prior to enabling this service it must be configured. This is a simple matter of configuring a sufficiently large share for the rock-ons to be installed into. It is possible to use the existing ‘out of the box’ home share but this is not recommended.
The following shows a Recommended Minimum 5 GB rock-ons-root share backed by a previously created pool named*** *****rock-pool

I am finding this a little confusing, does this mean that the rock pool has to have a disc to itself with a pool set up named rock-pool?

If not ( I don’t think it actually does but clarification would be appreciated), can it reside in the OS disc (240GB should be sufficient capacity for such stuff), if so, would shares be needed for rock-on roots, rock-on configs/data, and the rock-ons themselves, say 20 GB each perhaps.
Thanks in advance
PS Its beginning to look a tremendous system and I’m looking forward to extending thoughts/desires possibly to a web browser and plex service for the family videos/snaps etc.]

Detailed step by step instructions to reproduce the problem

[write here]

Web-UI screenshot

[Drag and drop the image here]

Error Traceback provided on the Web-UI

[paste here]
2

Hi @Mike-B,

Thanks for reaching out; I’ll try to address your questions below.

No, the rockons-root does not need to be in its own dedicated pool named rock-pool. The rock-pool name was just that: a name given as an example but I do see how this part of the documentation was not that clear and thus confusing; thanks a lot for bringing this up as we’ll correct that.
To be brief, all you need to do is to create a share that will be used as the rockons-root. You can name that share however you prefer, and you can create that share in whatever pool you prefer (a note on that below, though). The only requirement for this share is to use it only as the rockons-root share and nothing else; this is why I recommended above to use a dedicated share for it. The reason for this is that this share will be used by Docker to store and run all it needs; if this share is used by another application it will raise the risk of conflict and thus potentially breaking all your rock-ons. As there is no downside in creating another share, it is highly recommended to simply use a dedicated share for it.

Technically yes, but not necessarily recommended. Best practices would recommend you to use the OS disk to house the system, while using your other storage devices (hard drives, SSDs) for storing your data. This makes everything safer and easier if something were to happen to either your system or data devices. If you need to replace your OS disk, for instance, you can simply reinstall Rockstor on it and then re-import all your data pools in just one click. This ideal scenario is what best practices recommend and thus what we strive to recommend as well. That being said, we acknowledge and understand that some situations warrant the use of the OS disk for storing some sort of data (while understanding the risks it entails), so @phillxnet made sure it would still possible to do so. It can be argued that the rockons-root can fit this case as the data it contains is designed to be destroyed and recreated easily (this is what docker containers are supposed to be), though, so it would be preference on the matter. Note that I’m talking about the rockons-root only here, and not the shares used for rock-ons config/data; I strongly recommend against using the OS disk for that.

To give you an example, here’s what I have on my own system:
I have 3 hard drives. These three hard drives are used in a single Raid1 pool that I chose to name main_pool. I created a share that I chose to name rockons_root on this pool (I could have chosen any name for this share). I use that share as the “Root Share” in the Rock-ons service configuration window (https://rockstor.com/docs/_images/rockons_root_config.png). For each Rock-on, I create a dedicated share for each of the volumes that need to be bound. If I were to run the Syncthing Rock-on, for instance, I would create two shares: syncthing_conf and syncthing_sync (see https://rockstor.com/docs/_images/addstorage_settings_summary.png for explanation). All these shares are located on my main_pool pool.

Sounds good, indeed. Note that we do not enforce share size limits currently (see Shares — Rockstor documentation) so I would not worry about setting the right size for shares.

I hope this helps, and thanks again for bringing this up. I have created an issue on our Github repository to improve this section of our docs:

Thanks again, and let me know if anything isn’t perfectly clear as I realized I ended up being distracted a bit.

2 Likes
3

@Mike-B & @Flox
Re:

Are yes, sorry about that. The “rock” in rock-pool was for me a short for Rockstor not Rock-ons. Rock-ons are Rockstor addons = Rock-ons. I see now that the Rock name can thus be confusing. It was meant to be just a rockstor pool conglomeration that referenced a pool of say water in amongst some rocks :slight_smile: .

And what @Flox said as that was an excellent answer.

4

Thanks for the sharp and concise reply. It is a lot clearer now and I can see the reason for all data etc to be within a raid set up in order to protect against failure. The OS drive could be replaced without any loss which would not be the case had it held data related to Rock-ons.
Hope my query has helped others in the future.

2 Likes
5

The documentation has now been updated accordingly:

2 Likes