Since the time I issued, as root: # btrfs subvolume set-default 1112 /mnt2/cameras
and rebooted, I found the /mnt2/data (the whole BTRFS volume) is mounted pointing at subvolid=1112.
Actually, all shares (=subvolumes) were mounted with this vol id setting.
When I issued: # btrfs subvolume list /mnt2/cameras
I was later able to find the right snapshot to point at for every share.
What I’m not able to find now is the original subvolid to point at to mount the whole BTRFS filesystem in /mnt2/data and where this value is stored, finding the /etc/fstab doesn’t deal with its mounting (UUID not present).
If I try to mount the subvolid=5, then the response is it is already mounted as /mnt2/rockstor_rockstor.
Notice this mount uses a different device, specifically /dev/sda3.
/mnt2/data mounts the other /dev/sdd device.
I think it would help here if you explained more of what you are trying to achieve, or if you have in fact accomplished that and just want to return to a default Rockstor setup. From you explanation I’m not sure if you have made changes to the default /etc/fstab entries. If so they will have to be undone for normal Rockstor operations to resume.
By default, in a CentOS based install (ie an install from our current iso) fstab only deals with mounting the system related subvols as per:
#
# /etc/fstab
# Created by anaconda on Mon Oct 29 06:44:17 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=e6b2bcd6-4f2c-4925-ae8c-0116db7c1b6c / btrfs subvol=root 0 0
UUID=594120ac-7745-4b05-acc4-c2eca553e387 /boot ext4 defaults 1 2
UUID=e6b2bcd6-4f2c-4925-ae8c-0116db7c1b6c /home btrfs subvol=home 0 0
UUID=9936e8d4-5b5b-4b06-ba41-ffb5cacc0a2d swap swap defaults 0 0
ie subvol root and subvol home.
The set-default command you ran as root is intended to establish the default subvol to be mounted.
"A freshly created filesystem is also a subvolume, called top-level, internally has an id 5. This subvolume cannot be removed or replaced by another subvolume. This is also the subvolume that will be mounted by default, unless the default subvolume has been changed (see subcommand set-default).
A snapshot is a subvolume like any other, with given initial content. By default, snapshots are created read-write. File modifications in a snapshot do not affect the files in the original subvolume."
So it would seem that you may have intentionally or inadvertently altered which subvol is mounted by default by you stated command.
Note that there is a subvol = 5 for each pool. And in your case you have both the system pool labeled “rockstor_rockstor” (to be named ROOT in our pending openSUSE offerings) and whatever you have labelled your /dev/sdd data pool. And from the following I’m assuming this was ‘data’:
So if you paste the output of
btrfs fi show
folks here will have a better overview of what your arrangement is.
Also for all subvolumes:
btrfs subvol list /mnt2/pool-name
and for only snapshots:
btrfs subvol list -s /mnt2/pool-name
and to see the parent relationship of subvols you can use the “-p” option:
btrfs subvol list -p /mnt2/pool-name
Assuming the pool in question is mounted.
But in a few of these commands your changes to default-root could have misleading results.
And a generic install of CentOS based rockstor has as it’s default-root settings:
btrfs subvol get-default /
ID 5 (FS_TREE)
Newer versions of Rockstor code (stable channel currently) actually use this facility to account for openSUSE btrfs root arrangements that allow for ROOT (read system) pool roll back in grub. Our code to read this value, which is changed from under us by openSUSE’s roll back facility is as follows:
And for a data pool labeled “data” we also have:
btrfs subvol get-default /mnt2/data
ID 5 (FS_TREE)
If I understand at least part of your question here, the default-root command affects the filesystem directly. And excluding the initial system mounts dealt with via normal systemd fstab means, all other pools and Rockstor relevant subvols / snapshots are mounted programmatically by Rockstor itself at boot time or after creation. Although, somewhat confusingly at least to me, Rockstor also mounts the root associated pool/subvols again under it’s /mnt2 heierarchy: but these mounts are not relevant to the system boot by then.
On the plus side it looks like, if this post is related, that you may have retrieved / gained access, to your prior missing from Web-UI snapshot subvols that were inadvertently hidden by a share rollback to snapshot.
Apologies for the slightly confused reply here but theirs is actually quite a bit of complexity hidden by Rockstor, but there is always the command line. But note that Rockstor only surfaces a subset of btrfs’s capabilities in an attempt to keep things accessible for most use purposes. But we are working towards expanding our capabilities as we develop while maintaining ease of use (hopefully).
Also note that earlier versions of Rockstor, ie the testing channel (at least for now ), mounted it’s managed subvols via name, this was later improved to mount by subvol. You don’t mention which version of Rockstor you are running so that would also be a potentially useful addition here, ie:
yum info rockstor
And another element of this that you have most likely already fathomed but may be useful to add here is that all Rockstor managed / created snapshots are created under
), mounted it’s managed subvols via name, this was later improved to mount by subvol. You don’t mention which version of Rockstor you are running so that would also be a potentially useful addition here, ie: