I recently installed bees in order to make use of the deduplication feature. One of the things it does is create a btrfs subvolume called .beeshome, where it stores some logs, a hashfile. This gets mounted at the root of the btrfs pool.
So for example, I have a btrfs pool called BackupPool. I then have a share inside of that called BackupShare. Rockstor mounts these as:
/mnt2/BackupPool
/mnt2/BackupShare
After starting bees, it creates a subvolume under BackupPool so the structure looks like:
/mnt2/BackupPool/.beeshome
However, Rockstor picks this up, and treats it as a Share. So it also gets mounted under /mnt2 like:
/mnt2/.beeshome
It is also listed as a Share in the Rockstor GUI.
This wouldn’t be an issue, except that I have multiple pools. And if I run bees on each pool, I’ll have multiple .beeshome sub volumes (one per filesystem). I’m not sure what Rockstor will do, as it tries to mount all of these under /mnt2 as they will all appear to have the same name.
Ideally, it’d be nice if there was a way to tell Rockstor to ignore “shares” that aren’t created by Rockstor. Or if there was an interface to list subvolumes that rockstor should ignore. Or maybe even simply to just have Rockstor not mount sub volumes that start with a . (although not sure if that would cause other issues).
Yes, that is a current limitation. We have to have unique system wide subvol names unfortunately. At least currently.
Funny you should say that. There is. We don’t yet surface this but in newer versions of Rockstor there is a newly required mechanism to ignore some shares by name. What version of Rockstor is this?
yum info rockstor
It’s actually a list internally added as part of our migration to an openSUSE base via the ‘Build on openSUSE’ endeavour as they have a tone of subvols that we wanted to ignore.
See the following code. If you Rockstor is new-enough you should have this same list. Just add your ‘to be ignored’ subvol name there, stop then start the rockstor service, and it should go away. But won’t be unmounted. So you will need to do a reboot to ensure it’s still ‘away’ and double check that Rockstor has in fact not mounted it.
Your installed version of this should be in:
/opt/rockstor/
However I’ve just thought that this only pertains to the root subvol.
I may be able to come up with a hot patch, but it won’t be for a few days I’m afraid. But you may well be able to look in that same file and do a quick hack to just ignore this subvol. Rockstor considers what to mount by where it is, not by if it created it or not as we really can’t tell especially given the requirement to import and refresh invisibly. But a similar mechanism to the above but for system wide data pools would serve your purpose here.
Thanks for the report/observation and I think this would be a great addition indeed. Would you mind adding it as a GitHub feature request issue here:
An initial hard wired option, such as we already have for the ROOT pool, it could serve the likes of your particular, and likely others, “.beeshome” and any others that are just not appropriate to surface. That way it will be a simple addition. A custom Web-UI accessible addition with db backed settings is way more complicated and actually serves as an extention to the first. So if you make an issue for the hard wired built in exclusions that should be a fairly easy addition where we put stuff like the .beeshome which we will likely not want to surface at all anyway, especially since it can lead to breakage.
Nice find. So if you make that issue this could be a quick addition. But the custom Web-UI option will take a great deal longer to develope and prove and is, at this time, rather unlikely to materialise, but a background hardwired list we simply ignore should be a fairly simple addition actually. Especially given we have a precsedent already in the existing exclusion mechanism for root.
You could also add another GitHub issue for the Web-UI custom exclusion mechanism but again, it’s unlikely to see any attention from the core devs until we have our next Stable release out and have addressed some of our mounting technical debt.
Unfortunately it is a build from GitHub, not an RPM build. I think it was done around the time I did my code contribution earlier this year. I’ve been waiting to move over to the RPM builds once I switch over to OpenSUSE.
Yes, I do see that
I’ll try adding the subvolume here and doing a reboot at the next chance I get.
I’ll try and poke around this weekend, if I get some time, and see if just adding to the list works, or if more might be required.
@kupan787 Yes, that exclusion list is for the system volume only, i.e. the ROOT volume.
I’m hoping to have a look at this soon actually, and if it turns out to be a relatively simple/safe addition we may be able to pop it in the testing channel for a little while and slip it into the next Stable. But I’ve got one or two things to line up before that.
Thanks for the issue creation by the way. They were exactly what I was thinking. And the initial hard wired exclusion one is the only one I hope to get to soon. But that would be a start.
Could you give us a subvolume list so we can see exactly where this .beeshome subvol is located. Off from the top level was my reading for before. But just nipping by on this one so can’t look to closely right now; but the area I think we can pop this exclusion into is the same one that uses the ROOT_SUBVOL_EXCLUDE list:
So it would certainly help with the development of this new feature if your could provide the output of:
btrfs subvol list -s mnt_point
and
btrfs subvol list -p mnt_point
Where mnt_point is either “/” or “/mnt2/poolname” where you have one of these problematically visible subvols.
I may then be able to create a unit test to reproduce your issue and then work against that to provide the new all pools exclusion mechanism.
[root@rocknas ~]# btrfs subvol list -s /mnt2/ExternalBackup
ID 8873 gen 31286 cgen 31286 top level 3597 otime 2020-10-05 12:59:52 path backups/snapshots/imagesRO
[root@rocknas ~]# btrfs subvol list -p /mnt2/ExternalBackup
ID 3597 gen 61396 parent 5 top level 5 path backups
ID 8869 gen 61396 parent 5 top level 5 path .beeshome
ID 8873 gen 31286 parent 3597 top level 3597 path backups/snapshots/imagesRO
ID 8934 gen 58320 parent 3597 top level 3597 path backups/snapshots/duplicati_snap
So I’ve finally gotten around to creating a pull request to add a system wide subvol exclusion mechanism and have pre-populated it with your ‘problem’ ".beeshome’ subvol name:
As indicated previously this is the base hard-coded variant; I think it’s as well that we have this mechanism in place prior to our re-lauch via Rockstor 4 as then if we do come across such incompatibilities again there is at least a way-out. At least until we can do something a little more user-friendly/sophisticated.
Pull request is awaiting review, but does have an included unit test so I think we are relatively safe on this addition. If you fancy testing this in your environment then that would be great. The active code (in btrfs.py) is actually pretty trivial, as you will see from the pr.
Thanks for he command outputs by the way, most useful.
