<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Mar 12, 2018 at 12:32 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 12, 2018 at 07:13:52AM +0000, Nir Soffer wrote:<br>
> On Fri, Mar 9, 2018 at 4:25 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>> wrote:<br>
><br>
> > It has to be said it would be really convenient to have a 'zero'<br>
> > and/or 'trim' method of some sort.<br>
> ><br>
><br>
> 'trim' means discard?<br>
<br>
Yes.  The 5 functions we could support are:<br>
<br>
* pread  - done<br>
* pwrite - done<br>
* flush  - does fdatasync(2) on the block device<br></blockquote><div><br></div><div>Currently we do fsync() on every PUT request, so flush is not very</div><div>useful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* zero   - write a range of zeroes without having to send zeroes<br>
* trim   - punch hole, can be emulated using zero if not possile<br></blockquote><div><br></div><div>Makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also (not implemented in nbdkit today, but coming soon), pwrite, zero<br>
and trim can be extended with a FUA (force unit access) flag, which<br>
would mean that the range should be persisted to disk before<br>
returning.  It can be emulated by calling flush after the operation. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It wasn't clear if anything in this process flushes the content to<br>
disk.  Is that what transfer.finalize does?<br></blockquote><div><br></div><div>All PUT requests fsync() before returning. We optimize for complete image</div><div>trasfer, not for random io.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Currently we cannot support discard on block storage since ovirt may<br>
> need to wipe lvs when deleting a disk, and discarding may leave<br>
> unwiped user data. This may change in 4.3 if we switch to wipe on<br>
> creation instead of wipe after delete.<br>
<br>
I think this depends on BLKDISCARDZEROES[1] for the block device?  Of<br>
course if you're worried about data remanence for someone who has<br>
access to the physical device then that wouldn't be enough.<br></blockquote><div><br></div><div>BLKDISCARDZEROES was never reliable and it was removed from the</div><div>kernel recently. Please check <a href="https://patchwork.kernel.org/patch/9903757/">https://patchwork.kernel.org/patch/9903757/</a></div><div>We are not relying on it since ovirt 4.2, hopefully also in 4.1.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="https://rwmj.wordpress.com/2014/03/11/blkdiscard-blkzeroout-blkdiscardzeroes-blksecdiscard/" rel="noreferrer" target="_blank">https://rwmj.wordpress.com/2014/03/11/blkdiscard-blkzeroout-blkdiscardzeroes-blksecdiscard/</a><br>
<br>
> POST /images/ticket-id ...<br>
> ...<br>
> {<br>
>     "op": "zero",<br>
>     "offset": X,<br>
>     "size": Y<br>
> }<br>
><br>
> I would like to support only aligned offset and size - do you think it<br>
> should work<br>
> for qemu-img?<br>
<br>
It depends a bit on what you mean by "aligned" and what the alignment<br>
is.  We'd probably have to work around it in the plugin so that it can<br>
round in the request, issues a zero operation for the aligned part,<br>
and writes zeroes at each end.  There's no guarantee that qemu-img<br>
will be well-behaved in the future even if it is now.<br></blockquote><div><br></div><div>Aligned for direct I/O (we use direct I/O for read/write). We can support</div><div>non-aligned ranges by doing similar emulation in the server, but I prefer to do</div><div>it only if we have such requirement. If you need to do this in the client, we</div><div>probably need to do this in the server otherwise all clients may need to </div><div>emulate this.</div><div><br></div><div>I think there is no reason that qemu-img will zero unaligned ranges, but</div><div>I guess Eric can have a better answer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway this sounds do-able, is it something we can get for 4.2?<br></blockquote><div><br></div><div>I think it is for 4.2.z.</div><div><br></div><div>Is zero support in the daemon and proxy enough, or we need the other</div><div>options now?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How will we detect that the server supports it?<br></blockquote><div><br></div><div>Because we don't support OPTIONS yet, the only way is to send a POST</div><div>request and checking for 405 response.</div><div><br></div><div>Nir</div></div></div>