search for: notrim

...ilters/nozero/nbdkit-nozero-filter.pod index 7e06570..8e694bb 100644 --- a/filters/nozero/nbdkit-nozero-filter.pod +++ b/filters/nozero/nbdkit-nozero-filter.pod @@ -18,14 +18,19 @@ testing client or server fallbacks. =over 4 -=item B<zeromode=none|emulate> +=item B<zeromode=none|emulate|notrim> Optional, controls which mode the filter will use. Mode B<none> -(default) means that zero support is not advertised to the client; -mode B<emulate> means that zero support is emulated by the filter -using the plugin's C<pwrite> callback, regardless of whether the -plug...

This is a subset of the last half of the larger 9-patch series. The uncontroversial first half of that series is pushed, but here, I tried to reduce the size of the patches by splitting out some of the more complex changes, so that the rest of the changes remaining in the series are more mechanical. In turn, it forced me to write timing tests, which let me spot another spot where we are wasting

...prime the .can_write cache according to .open. The same script from the previous patch now fails a lot faster under -r (since nozero is not a filter that changes readonly=false to true, the plugin now fails .can_zero quickly): $ /bin/time -f %e ./nbdkit -U - -r --filter=nozero sh script zeromode=notrim \ --run 'qemu-nbd --list -k $unixsocket >/dev/null' nbdkit: sh[1]: error: zeromode 'notrim' requires plugin zero support qemu-nbd: Failed to read initial magic: Unexpected end-of-file before all bytes were read Command exited with non-zero status 1 0.06 Signed-off-by: Eric Bla...

...phone.com [guest] disallow=all allow=ulaw connection=whitehat238 context=googlein ##extensions_custom.conf## exten => whitehat238 at gmail.com ,1,Set(CALLERID(name)=${CUT(CALLERID(name),@,1)}) exten => whitehat238 at gmail.com,n,GotoIf($["${CALLERID(name):0:2}" != "+1"]?notrim) exten => whitehat238 at gmail.com,n,Set(CALLERID(name)=${CALLERID(name):2}) exten => whitehat238 at gmail.com ,n(notrim),Set(CALLERID(number)=${CALLERID(name)}) exten => whitehat238 at gmail.com,n,Answer exten => whitehat238 at gmail.com,n,Wait(1) exten => whitehat238 at gmail.com,n...

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

...o_zero (struct nbdkit_next_ops *next_ops, void *nxdata, void *handle, uint32_t count, uint64_t offs, uint32_t flags, int *err) { + int writeflags = 0; + bool need_flush = false; + assert (zeromode != NONE); flags &= ~NBDKIT_FLAG_MAY_TRIM; if (zeromode == NOTRIM) return next_ops->zero (nxdata, count, offs, flags, err); + if (flags & NBDKIT_FLAG_FUA) { + if (next_ops->can_fua (nxdata) == NBDKIT_FUA_EMULATE) + need_flush = true; + else + writeflags = NBDKIT_FLAG_FUA; + } + while (count) { /* Always contains zeroes, b...

...ways want to use FALLOC_FL_PUNCH_HOLE unless it is not supported. Seems that we need to add a "trim" or "punch_hole" flag to the PATCH/zero request, so you can hint oVirt how do you want to zero. oVirt will choose what to do based on storage type (file/block), user request(trim/notrim), and disk type (thin/preallocated). I think we can start the use this flag when we publish the "trim" feature. Nir

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

On Tue, Apr 10, 2018 at 02:07:33PM +0000, Nir Soffer wrote: > This makes sense if the device is backed by a block device on oVirt side, > and the NBD support efficient zeroing. But in this case the device is backed > by an empty sparse file on NFS, and oVirt does not support yet efficient > zeroing, we just write zeros manually. > > I think should be handled on virt-v2v plugin