For LXD, do zpool ashift, atime & xattr properties matter? How about dataset encryption & compression?

For setting up LXC to use a pre-existing pool & dataset: zfspool/lxd

When creating zfspool, would setting up with the following make any difference / have any downsides for LXD:

sudo zpool create -m /zfs/zfspool -o ashift=12 -O atime=off -O xattr=sa zfspool mirror /dev/sda3 /dev/sda4


And when the zfspool/lxd dataset is created to use for LXD:

Name of the existing ZFS pool or dataset: zfspool/lxd

With zfspool/lxd dataset created via:

sudo zfs create -o compression=zstd -o encryption=on -o keylocation=file:///etc/zfs/secret.key -o keyformat=passphrase zfspool/lxd

Would the use of compression and/or encryption on the zfspool/lxd dataset cause any problems for LXD? Or other downsides? Or is it more ideal to create via: “sudo zfs create zfspool/lxd” ?

I actually forgot that LXD moved away from last summer.

Tried to change my question title, but maybe this question can be considered regarding Incus and LXD.

As far as I can tell, the general consensus with zfs seems to be “use the defaults”.

Nobody’s going to argue against ashift=12 though (it should be default these days), and compression is almost always a good thing: the (small) CPU hit for compression/decompression is more than offset by the reduction in I/O.

Personally I don’t see any benefit in encryption when the encryption key is stored on local disk on the same system, but that’s for your own situation and risk profile to decide.

All of this is transparent to lxd/incus: it’s just another workload, and containers are just processes.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.