search for: 964cce9f

...ely supported (every write needs it). Missed in commit df0cc21d. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/nozero/nozero.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/filters/nozero/nozero.c b/filters/nozero/nozero.c index 035caae3..964cce9f 100644 --- a/filters/nozero/nozero.c +++ b/filters/nozero/nozero.c @@ -1,5 +1,5 @@ /* nbdkit - * Copyright (C) 2018 Red Hat Inc. + * Copyright (C) 2018-2019 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the fol...

Another couple things I noticed that are worth improving, but aren't strictly related to implementing fast zero support. Eric Blake (2): server: Assert sane error responses nozero: More efficient FUA handling filters/nozero/nozero.c | 17 +++++++++++-- server/filters.c | 56 +++++++++++++++++++++++++++++++++-------- server/protocol.c | 32 +++++++++++++++++------ 3 files

...= "nbdkit noparallel filter", - .version = PACKAGE_VERSION, .config = noparallel_config, .config_help = noparallel_config_help, .thread_model = noparallel_thread_model, diff --git a/filters/nozero/nozero.c b/filters/nozero/nozero.c index 964cce9f..9187ec33 100644 --- a/filters/nozero/nozero.c +++ b/filters/nozero/nozero.c @@ -139,7 +139,6 @@ nozero_zero (struct nbdkit_next_ops *next_ops, void *nxdata, static struct nbdkit_filter filter = { .name = "nozero", .longname = "nbdkit nozero filter",...

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a

It's easy to use the sh script to demonstrate that nbdkit is inefficiently calling into .get_size, .can_fua, and friends more than necessary. We've also commented on the list in the past that it would be nice to ensure that when filters call into next_ops, they are not violating constraints (as we've have to fix several bugs in the past where we did not have such checking to protect