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

Richard W.M. Jones rjones at redhat.com
Fri Jun 10 11:47:39 UTC 2022


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
-- 
2.35.1



More information about the Libguestfs mailing list