I’m playing around LXD & dedicated block device for BTRFS, and a bit amused of handling standard ops with such setup, i.e.:
not shown in mount lists
not shown in lsblk
not sure how to check compression ratios
i’ve did lxc storage set poolbtrfs btrfs.mount_options 'compress=zstd:3' , but see no options in lxc storage info poolbtrfs
as it’s not shown in any mountpoints, not sure how it’s supposed to be monitored (say Nagios, Zabbix …) for disk space/inodes/…
And so on.
I guess it’s on purpose and someone who architect it like that, had ideas behind this on standard operations tools and flow, but i’m not getting that idea (yet).
Would be interesting to know how things supposed to work and other’s experience with BTRFS here.
Thanks @simos
Yes, I do understand that things live under mount namespaces and not visible from (main, root, primary?) namespace - thus I have a question, how things supposed to integrate with other tooling, for example disk usage monitoring (to ensure I have space on pool).
coming to btrfs question, situation is quite simple - tooling is not available inside that namespace, see:
This is a side effect of the snap packaging, rather than something specific to LXD.
For storage pool drivers, such as LVM or ZFS, using the host tooling will show the LXD volumes as normal.
As @simos mentioned you can switch into the LXD snap’s mount namespace, and then because the snap package comes with its own tooling for each storage driver, these are available at a different location, in this case the btrfs tool is at:
/var/lib/snapd/hostfs/snap/lxd/current/bin/btrfs
@stgraber do you have any comment on this topic? Thanks
Possibly the other option you could use is to use an existing BTRFS filesystem mounted on the host and then create a LXD BTRFS storage pool using the existing filesystem using the source property when creating the storage pool. This way the host filesystem should still be able to see the LXD subvolumes.
Here’s an example using a loopback file (not recommended for production setups):