Re: [Qemu-devel] [PATCH 3/8] migration: support to detectcompression and decompression errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 03/28/2018 08:43 AM, jiang.biao2@xxxxxxxxxx wrote:
On 03/27/2018 07:17 PM, Peter Xu wrote:
On Tue, Mar 27, 2018 at 03:42:32AM +0800, Xiao Guangrong wrote:

[...]

It'll be understandable to me if the problem is that the compress()
API does not allow the input buffer to be changed during the whole
period of the call.  If that is a must, this patch for sure helps.

Yes, that is exactly what i want to say. :)

So I think now I know what this patch is for. :) And yeah, it makes
sense.

Though another question would be: if the buffer is updated during
compress() and compress() returned error, would that pollute the whole
z_stream or it only fails the compress() call?


I guess deflateReset() can recover everything, i.e, keep z_stream as
it is init'ed by deflate_init().

(Same question applies to decompress().)

If it's only a compress() error and it won't pollute z_stream (or say,
it can be recovered after a deflateReset() and then we can continue to
call deflate() without problem), then we'll actually have two
alternatives to solve this "buffer update" issue:

1. Use the approach of current patch: we copy the page every time, so
     deflate() never fails because update never happens.  But it's slow
     since we copy the pages every time.

2. Use the old approach, and when compress() fail, we just ignore that
     page (since now we know that error _must_ be caused by page update,
     then we are 100% sure that we'll send that page again so it'll be
     perfectly fine).


No, we can't make the assumption that "error _must_ be caused by page update".
No document/ABI about compress/decompress promised it. :)
So, as I metioned before, can we just distingush the decompress/compress errors
from errors caused by page update by the return code of inflate/deflate?
According to the zlib manual, there seems to be several error codes for different
cases,
#define Z_ERRNO        (-1)
#define Z_STREAM_ERROR (-2)
#define Z_DATA_ERROR   (-3)
#define Z_MEM_ERROR    (-4)
#define Z_BUF_ERROR    (-5)
#define Z_VERSION_ERROR (-6)
Did you check the return code when silent failure(not caused by page update)
happened before? :)

I am afraid there is no such error code and i guess zlib is not designed to
compress the data which is being modified.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux