[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 3/8] migration: support todetectcompressionand

From: jiang.biao2
Subject: Re: [Qemu-devel] [PATCH 3/8] migration: support todetectcompressionand decompression errors
Date: Wed, 28 Mar 2018 16:07:33 +0800 (CST)

> On 03/28/2018 12:20 PM, Peter Xu wrote:
>> On Wed, Mar 28, 2018 at 12:08:19PM +0800, address@hidden wrote:
>>>> On Tue, Mar 27, 2018 at 10:35:29PM +0800, Xiao Guangrong wrote:
>>>>>>> No, we can't make the assumption that "error _must_ be caused by page 
>>>>>>> update".
>>>>>>> No document/ABI about compress/decompress promised it. :)
>>>> Indeed, I found no good documents about below errors that jiang.biao
>>>> pointed out.
>>> Hi, Peter
>>> The description about the errors comes from here,
>>> http://www.zlib.net/manual.html
>>> And about the error codes returned by inflate(), they are described as,
>>> ** inflate() returns
>>> Z_OK if some progress has been made (more input processed or more output 
>>> produced),
>>> Z_STREAM_END if the end of the compressed data has been reached and all 
>>> uncompressed output has been produced,
>>> Z_NEED_DICT if a preset dictionary is needed at this point,
>>> Z_DATA_ERROR if the input data was corrupted (input stream not conforming 
>>> to the zlib format or incorrect check value, in which case strm->msg points 
>>> to a string with a >more specific error),
>>> Z_STREAM_ERROR if the stream structure was inconsistent (for example 
>>> next_in or next_out was Z_NULL, or the state was inadvertently written over 
>>> by the application),
>>> Z_MEM_ERROR if there was not enough memory,
>>> Z_BUF_ERROR if no progress was possible or if there was not enough room in 
>>> the output buffer when Z_FINISH is used. ...
>>> **
>> Ah yes.  My bad to be so uncareful. :)
>>> According to the above description, the error caused by page update looks
>>> more like tend to return Z_DATA_ERROR, but I do not have env to verify 
>>> that. :)
> No, still lack info to confirm the case of compressing the data being
> updated is the only one to return Z_DATA_ERROR. And nothing provided
> that no other error condition causes data corrupted will be squeezed
> into this error code.
>>> As I understand it, the real compress/decompress error cases other than that
>>> caused by page update should be rare, maybe the error code is enough to
>>> distinguish those if we can verify the the error codes returned by page 
>>> update
>>> and other silent failures by test. If so, we can cut the cost of memcpy.
> Please note, compare with other operations, e.g, compression, detect zero 
> page,
> etc., memcpy() is not a hot function at all.

Just out of curiousity, what's level of memory num need to be copied for 
normal cases? KBs, MBs? 

>>> If not, I agree with Guangrong's idea too. I never read the zlib code and 
>>> all my
>>> information comes from the manual, so if anything inaccurate, pls ignore my
>>> option. :)
>> So I suppose all of us know that alternative now, we just need a solid
>> way to confirm the uncertainty.  I'll leave this to Guangrong.
> Yes, i still prefer to memcpy() to make it safe enough to protect our 
> production
> unless we get enough certainty to figure out the error conditions.

Indeed, no garantee for that currently, so for safe, we need memcpy(). 
Never mind, pls just ignore my opinion. :)  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]