rockstor / rockstor-core

Linux/BTRFS based Network Attached Storage(NAS)
http://rockstor.com/docs/contribute_section.html
GNU General Public License v3.0
550 stars 137 forks source link

Block creation of system reserved Share names #2881

Closed phillxnet closed 3 weeks ago

phillxnet commented 1 month ago

Thanks to forum member andyz for highlighting this issue. We have a hard limitation regarding unique btrfs vol (Pool) and btrfs subvol (Share) naming. But prior to (current testing phase):

Un special-case system drive btrfs-in-partition treatment #2824 #2835

we always auto imported the ROOT system Pool (btrfs vol), with it's 'special' home Share (btrfs subvol). And similarly identified this home Share by name as 'special': limiting the available functions as a result. But we are now missing a block against folks creating a home Share which would prior to the referenced changes always already exist. So our existing no-duplicate Share/Pool names block avoided the duplication.

Ergo we now need to guard against folks creating a home Share via the Web-UI as this would then cause a potential clash if, at a later date, folks wanted to import the system Pool. It would also introduce a source of confusion re two subvols named the same - which we normally avoid via our existing hard limitation.


Forum thread reference: https://forum.rockstor.com/t/newly-created-test-share-named-home-cannot-be-resized-nor-deleted/9620

phillxnet commented 1 month ago

N.B. similarly we should block all default subvol names found on our upstream OS ROOT pool. As we filtered most out from the Web-UI and surfaced only home by way of continuity form our prior OS base of CentOS which has a very different arrangment btrfs wise. But we aimed to make user transition as smooth as possible: hence this gradual transition to proper system/data separation re no default system pool import etc.

Hooverdan96 commented 1 month ago

Do you think that will end up being a static filter, or is there a way to suss out the existing ones and add to a filter set? Not sure that these things change all that much in upstream, so a dynamic way might be overkill?

phillxnet commented 1 month ago

@Hooverdan96 Not sure really. There is also a complexity wrinkle re subvolumes as we default to boot to snapshot. I remember it being quite tricky to assess root subolumes in a boot to snapshot arrangement (our default) and we account for non boot-to-snapshot also. So I think, at this stage in testing, I was going to opt for the default filesystem arrangement as per openSUSE which I think is not likely to change that much. We can enhance some later: and we currently have a static filter for removing them form the Web-UI so I was hoping we can use the same to also block their creation also.

phillxnet commented 1 month ago

Having a quick look now - given we need to get Stable out as soon as possible.

This is our existing excludes for subvols not to display/concern ourselves with: https://github.com/rockstor/rockstor-core/blob/4d60a2c683140aaa10a8e5b201157163cc9a898b/src/rockstor/fs/btrfs.py#L57-L84

I'm thinking, at least initially, that we exclude the creation of all SUBVOL_EXCLUDE (which should be Web-UI excludes) and have an additional list containing 'home', so we still show home on ROOT pool import but have it blocked via it's own blacklist.

That static list has thus-far served us for the entire life-cycle of Leap 15.0 (from beta). So it should serve us OK for the remainder of Leap at least: fingers crossed.

phillxnet commented 3 weeks ago

Closing as: Fixed by #2882