6:47 a.m.
Eric: This seems like a bug in nbdkit, but this patch just does the
easy fix. What do you think?
Two other filters can return NBDKIT_ZERO_EMULATE:
filters/ext2/ext2.c: return NBDKIT_ZERO_EMULATE;
filters/nozero/nozero.c: return NBDKIT_ZERO_EMULATE;
nbdkit-ext2-filter doesn't crash, but it doesn't emulate either and it
seems broken. It calls down to the underlying plugin (which will
either emulate or true zero). I believe it may be zeroing a random
offset in the underlying disk.
Rich.
6:47 a.m.
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
7:03 a.m.
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?
7:04 a.m.
On Fri, Jun 10, 2022 at 02:03:28PM +0200, Laszlo Ersek wrote:
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?
Yup!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
860
days inactive
860
days old
3 comments
2 participants
participants (2)
-
Laszlo Ersek -
Richard W.M. Jones