As discussed in here, I encountered some BUGs when using linstor as storage backend of incus.
I can use linstor storage-pool create zfsthin aaa incus tmp-pool/incus to create a linstor storage pool on an encrypted zfs pool, and then set it as the backend of the incus. However, when lunching containers in incus, incus started a clone operation, and the linstor seems not handled the clone operation on encrypted zfs pool correctly, as it reported:
linstor err show 68176B7C-B37A4-000000
ERROR REPORT 68176B7C-B37A4-000000
============================================================
Application: LINBIT® LINSTOR
Module: Satellite
Version: 1.31.0
Build ID: a187af5c85a96bb27df87a5eab0bcf9dd6de6a34
Build time: 2025-04-08T09:36:27+00:00
Error time: 2025-05-04 13:29:37
Node: aaa
Thread: clone_ZFS_COPY(incus-volume-113d198b22bb4085bb18ba29ee3a0d36/0->incus-volume-b838c402629d4b55968172d6d262453d/0)
============================================================
Reported error:
===============
Category: LinStorException
Class name: LinStorException
Class canonical name: com.linbit.linstor.LinStorException
Generated at: Method 'run', Source file 'CloneDaemon.java', Line #137
Error message: None 0 exit from: [timeout, 0, bash, -c, set -o pipefail; zfs send --embed --large-block tmp-pool/incus/incus-volume-113d198b22bb4085bb18ba29ee3a0d36_00000@CF_ad1d8095 | zfs receive -F tmp-pool/incus/incus-volume-b838c402629d4b55968172d6d262453d_00000 && zfs destroy -r tmp-pool/incus/incus-volume-b838c402629d4b55968172d6d262453d_00000@%]
ErrorContext:
Description: Clone command failed
Cause: cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one
Call backtrace:
Method Native Class:Line number
run N com.linbit.linstor.clone.CloneDaemon:137
run N java.lang.Thread:1583
END OF ERROR REPORT.
According to the openzfs document, using zfs send will cause zfs to decrypt the encrypted volume and send it. zfs recv cannot receive decrypted data streams on encrypted volumes. An additional --raw option can make zfs send not decrypt when sending.
It seems zfs is fully supported according here while zfs native encryption is not supported as discussed in this issue. However, personally I don’t think that a zfs support without zfs native encryption can be called a “fully support”.
I think that this problem can be solved by simply changing the zfs send --embed --large-block in doZFSCopy to zfs send --raw --embed --large-block to let zfs send encrypted streams.