Re: [Libguestfs] [PATCH nbdkit] luks: Don't advertise zero support

Fix an assertion failure in nbdkit: $ qemu-img create -f luks --object secret,data=LETMEPASS,id=sec0 -o key-secret=sec0 encrypted.img 100M Formatting 'encrypted.img', fmt=luks size=104857600 key-secret=sec0 $ rm -f data.img $ truncate -s 100M data.img $ nbdkit file encrypted.img --filter=luks passphrase=LETMEPASS --run 'nbdcopy data.img $nbd' -v ... nbdkit: file.10: debug: luks: zero count=104857600 offset=0 may_trim=1 fua=0 fast=0 nbdkit: backend.c:718: backend_zero: Assertion `c->can_zero > NBDKIT_ZERO_NONE' failed. It's always wrong for filters to try to return NBDKIT_ZERO_EMULATE, at least with the current implementation of the server. This is because emulation is only done at the plugin layer (see server/plugins.c: plugin_zero), and not at the filter layer. We could adjust nbdkit's filter layer (server/filter.c:filter_zero) to do similar emulation, but an easier solution here is not to advertise it to the client at all. In future we should adjust the LUKS plugin so it does whatever the kernel does for trimming/zeroing. --- filters/luks/luks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/filters/luks/luks.c b/filters/luks/luks.c index 8ad3f4ec..9c1a3389 100644 --- a/filters/luks/luks.c +++ b/filters/luks/luks.c @@ -189,7 +189,7 @@ luks_can_trim (nbdkit_next *next, void *handle) static int luks_can_zero (nbdkit_next *next, void *handle) { - return NBDKIT_ZERO_EMULATE; + return NBDKIT_ZERO_NONE; } static int