@kupan787 Hello again.
Re:
Yes, good point:
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.
Hope that helps.