In the last TrueNAS Tech Talk of 2024, @kris and @HoneyBadger bust a few more myths about SLOG sizing, the famous “80% Rule” about free space in ZFS and TrueNAS, talk about the progress of TrueNAS in 2024 and do a live demo of an exciting new feature to look forward in 2025 - Incus/LXC Linux Container support, coming out in TrueNAS 25.04!
Incus/LXC is looking very promising already! 
One thing you didn’t show in the video demo, unless I missed it, is how each container ties into a dataset.
This is important to me, since it has effects on:
<designated-pool>/iocage/jails/<jailname>/root)I especially want to use a modestly high level of ZSTD compression for the container datasets, as Linux root filesystems are very compressible.
Since I use Core with jails, I’ll share the following:
My FreeBSD jails use ZSTD-9 inline compression, and the savings are notable, without any performance penalty from what I could experience. In fact, it may even be a slight performance boost, since there is less data to pull from disk.
As for encryption, as long as it can inherit the pool’s root dataset encryption, then it will be on par with Core. (Currently, all my jails and their root filesystems are encrypted, and it is entirely seamless. There’s no worry about logs or other data “spilling” into an unencrypted space.)
Even better would be to prompt the user, during the creation of the first container, on what compression and encryption to use for these datasets.
Ho-ho-ho, Die Hard is a Christmas movie and anyone who says otherwise is wrong.
I will die on that hill.
Isn’t it better that each LXC container just be attached to a nominated dataset ?.. that way you have full control of properties and hierarchy.
Each container has a dataset which is cloned from an image, itself a dataset.
The containers support snapshots, cloning, rollback etc.
You can probably change the properties of these containers, I suspect incus doesn’t care too much.
When using incus on TrueNAS A hidden “default” “zfs” “storage pool” is made on the selected pool called “ix-virt”
Not sure how much of this behavior is exposed in the GUI
Do these “per-container” datasets inherit the ix-virt dataset properties, including recordsize, compression, and encryption? Or are they always set to something like “128K”, “LZ4”, and “unencrypted”, no matter what?
Is this ix-virt parent dataset visible and manageable in the GUI, in the same way that iocage is?
Where does ix-virt initially get its properties? Inherited by the pool’s root dataset? (This would be especially important for encryption.)
This won’t be as useful if they cannot be set before creating a container. (To use compression as an example, if you can only set the recordsize and compression property after creating a container, then it will not use something like “1M” and “ZSTD-9” for the highly compressible blocks of the container’s filesystem.)