Safest way to unmount Pool/Shares?

[phillxnet (Philip Guyton)]

@kupan787 Hello again.

I can chip in on this one:

As @dlsound stated, Rockstor is very keen on re-mounting whenever if finds something unmounted and just goes ahead and does it. In their case, as they state, they have LUKS on their side to effectively remove the open LUKS container device once they have unmounted everything related.

@kupan787

a) Temp disable the service prior to unmounting, and then reenabling the service after I have disconnected my chassis.

which I think is the way to go:

Rockstor has the following 3 systemd services, in execution order:

rockstor-pre
rockstor
rockstor-bootstrap

so you could stop the lot via:

systemctl stop rockstor-pre rockstor rockstor-bootstrap

You should then be down to a bare CentOS system.

Re-starting once you are done, due to the defined systemd inter dependencies, would be via:

systemctl start rockstor-bootstrap

We had a related question (but to disable all rockstor services at boot) asked recently by @Jorma_Tuomainen in the following forum thread:

Moving pool on top of LUKS in-place

@Jorma_Tuomainen Re: Yes that looks like the best way to do it in your circumstance. All Rockstor systemd services begin with “rockstor” and can be found in: ls -la /etc/systemd/system/rockstor* -rw-r--r-- 1 root root 217 Oct 15 18:48 /etc/systemd/system/rockstor-bootstrap.service -rw-r--r-- 1 root root 204 Oct 15 18:48 /etc/systemd/system/rockstor-pre.service -rw-r--r-- 1 root root 227 Oct 15 18:48 /etc/systemd/system/rockstor.service So systemctl disable on all of those: systemctl disabl…

There are plans (read hopes) to extend Rockstor’s Web-UI to be able to mount / unmount and mark pools and consequently all of their subvols as not to be auto mounted but unfortunately we have quite a few things that need sorting before we arrive at these more refined capabilities.

Re:

@kupan787

… do I need to unmount all of the shares first, and then the pool?

Yes I would go this way as each share mount (btrfs subvol) is a kind of file system in it’s own right. But to make things simpler all Rockstor initiated mounts are under /mnt2.

You could even go the ‘heavier’ route and disable all service completely, as per the linked thread. That way you would have no Rockstor ‘interference’ if you had to reboot the machine. Once you restart the associated rockstor services they should pickup from where they left. And their is auto scanning anyway so it should read the current state and pickup from their.

Note that if you end up restarting Rockstor services with the chassis disconnected it will show a bunch of detached disks for all prior Rockstor managed pool members that are now ‘gone’. But this should sort itself out upon re-connection. But this is not a particularly well tested function however. But the stable channel code is likely to fair far better given the additional 2 years of development now. Hope it works out for you and do report on your findings. Also if you are on the stable channel make sure to be running the latest their as their were a number of disk / pool management improvements just recently. As to the reconnection procedure: I’d go with stopping all rockstor services (if running) just prior to the re-connecting and then starting them their after myself as their are additional ‘getting it’s stuff together’ bits that are run in these services upon boot, which is what you would be enacting form Rockstor’s perspective when stopping them all and starting them again.

Hope that helps and let us know how you get on. Would definitely be nice to have more control over auto mount of pools etc but not currently a priority.