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

On 06/10/22 13:47, Richard W.M. Jones wrote: > 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 > so this is withdrawn now, right?