Closed phillxnet closed 3 weeks 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.
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?
@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.
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.
Closing as: Fixed by #2882
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 thishome
Share by name as 'special': limiting the available functions as a result. But we are now missing a block against folks creating ahome
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