Installed LXD 2.12 on a Ubuntu 16 server, ran the “lxd init” command, and specified a btrfs back end storage volume. I noticed the default mount parameters for btrfs were:
rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/
How can I add additional options to the default mount options like “compression=lzo, autodefrag”? Right now, I manually mount the volume via /etc/fstab but would like to have lxd mount the volume if possible.
That’s a good point! Could you open an issue for this on https://github.com/lxc/lxd, link to this thread and ping me (@brauner), please?
as soon it’s in fstab the btrfs drive get’s mounted automatically at system boot (or do I get something terribly wrong here?).
wouldn’t it be the easiest way to just add the mount options you want to the fstab entry?
Yes, it is easier to set the options in /etc/fstab. However, it would be ideal if "lxd init” allowed you to specify the filesystem mount options (via config file?). Currently, I believe they are hard coded.
I actually wasn’t aware that initiating a storage pool in lxd somewhat does come with automated mounting apparently.
I think it would be the most obvious way whether it would just create a line in the fstab. Actually it seems to work different though which is not really visible with standard tools (and therefore maybe less configurable
It’s against Debian and Ubuntu packaging policies for a package (in this case LXD) to alter configuration files from other packages (like /etc/fstab).
/etc/fstab is generated by the system installer and then modified by hand by the user. So that’s not a great fit for LXD.
Other software that also need additional auto-mount seems to be using systemd mount units, though we’ve also been trying to stay away from such direct ties to systemd in LXD so far as not all distributions that ship LXD are using it as their init system.
So yes, when LXD manages your storage pools (LXD 2.9 or higher), it will mount them as needed after creation and on subsequent LXD startups. Allowing to pass additional mount options through pool configuration seems reasonable to me.
@brauner I think this should be btrfs.mount_options or something along those lines as I believe it’s the only storage backend which would have pool-level mount options. ZFS doesn’t really use mount flags and has per-filesystem mounts, LVM doesn’t have pool mount options and we have a config key for LV mount options already. Am I missing something?
@stgraber, having ab btrfs.mount_options field was exactly what I had in mind. That’s why I was asking for a github issue. 
awesome to see how quick things can move (even though your last test apparently failed). I once again wish I could help but can’t code whatsoever
Sorry for the delay in opening the issue on github - it is there now: https://github.com/lxc/lxd/issues/3268
Not a problem. We move the discussion of this specific feature over to github I’d say.
We merged the commit. The feature should be available with the next LXD (2.14) release.
I guess it would make things perfect in this regards whether the way to use this was added to the the output of lxc config --help (which is how it’s going to work if I am not mistaken) then, right?
If anyone could explain to me how that can be achieved I’d be happy to contribute (0 experience with ‘help’ files or ‘manpages’ here though)
The way to add mount options to your btrfs storage pool would be
lxc storage <pool-name> btrfs.mount_options "rw,nospace_cache,lazytime,user_subvol_rm_allowed"An example could be added to the help message, for that, you’d need:
here you go https://github.com/lxc/lxd/pull/3274 hope it’s workable
Is this relevant if the added example in the storage.go file just get’s merged into master and shipped (same as the actual new feature) with the 2.14 release?
Yes, whenever a string is modified anywhere in the client the translation templates must be updated so that weblate can pick it up and have people translate the updated version.
so if it IS relevant now … I need to …
right?
You can update an existing PR by using “git push --force” to overwrite the current content, saves you from having to re-submit. Alternatively we can run those for you and push to your branch (so long as you allow us to, which I believe Github does by default now).