Safest way to unmount Pool/Shares?

[kupan787 (Ben)]

Hello.

I am wondering what is the safest way to unmount a Pool/Shares from Rockstor?

The reason I ask, I have an external chassis connected via SFF-8088. This chassis will have its own BTRFS pool setup. If I want to do any work on it, I’d like to be able to safely unmount the Pool (and associated drives?) so that I can power down the chassis and do work, without powering down the entire NAS.

I’m assuming I could go to where the Pool is mounted, and do a:

umount /mnt2/ExtChassis

But what I am unsure is if that will safely unmount all Shares that are on that pool, or do I need to unmount all of the shares first, and then the pool? Also, will Rockstor try to automatically remount when it sees the pool as unmounted? Or is there a command I can execute to remount the Pool once I bring the chassis back online?

[dlsound (Darrell L)]

I do something similar with my offsite backups and I am interested in this topic as well. I am not suggesting my procedure is good or healthy, but it has been working for me. I have found the rockstor wants to remount fairly quickly. and I’m using LUKS full drive encryption for these drives i’m moving around.I have a little bit of advantage because I can make the unencrypted LUKS virtual drive disappear quickly before rockstor can remount whereas you would need to physically unplug your drive before rockstor remounts. I should also mention I created the LUKS containers and volumes all in rockstor. However, my mounting, unmounting is done in CLI. I have also on ly tried this with single disks. I’m not sure I would try this with any multi-disc pool because I think I would need to get all shares and pools unmounted as well as LUKS closed before Rockstor notices.

Here is my procedure:

Connecting.
plugin drive to HBA JBOD Card
Unlock LUKS volume.
Hit rescan in rockstor GUI on the disks page. Rockstor sees my previously connected unencrypted volume and mounts it.

Disconnecting: (of course I need to be sure there is no filesystem activity when this is happening)
Rescan Disks in Rockstor GUI
umount /mnt2/share
umount /mnt2/pool
crypsetup close luks…
Rescan Disks in Rockstor GUI (i think this is important to make sure Rockstor notices the disk missing)

Rockstor can’t do anything with a locked LUKS volume so I can take my time physically unplugging from HBA.

If i miss unmounting the share rockstor will complain and keep trying to access disk, but if I get this done quickly enough rockstor seems happy and I have no complaints in dmesg

[kupan787 (Ben)]

I wonder what service runs to remount drives…

I’m going to try and do some digging, and see if there is a way to either:

a) Temp disable the service prior to unmounting, and then reenabling the service after I have disconnected my chassis.
b) Add some kind of a delay on the rerun of the service (5 minutes?), something to just give me enough time to unplug the chassis.

[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.

[kupan787 (Ben)]

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

So in my case, I don’t want to completely disable rockstor, just the remounting piece. But maybe that is not separated out, so stopping everything is the only option (for right now).

For my setup, I have two boxes with disks. The main “NAS” which runs the OS (in this case RockStor) and has 10 local disks. I then have a disk chassis, which will soon be populated with 10-15 disks. The two boxes are to be connected via a sff-8088 cable.

So if I want to do work on the disk chassis (say, replace a fan, add a disk, etc), I don’t want to power everything down, nor do I want to take down all of Rockstor.

What I was hoping was to find a way to just take down the pool that the chassis has, and then disconnect the chassis. I understand Rockstor would see that as unmounted / gone, which is fine. Then whenever I was done with the work, reattach and power on the chassis. Then somehow trigger Rockstor to remount the pool and shares.

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.

It sounds like this is what I would be looking for. But sounds like it is behind a few things, which is understandable. I don’t know that my use case is all that common.

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.

Thanks for the heads up here. I’ll have to play around with how this works, and see how it goes.

I’m probably a few weeks away from having all of the hardware in place to complete my build. But once I get things going, I’ll have to try a few iterations and see what appears to work best.