> On 03/28/2018 12:20 PM, Peter Xu wrote: >> On Wed, Mar 28, 2018 at 12:08:19PM +0800, jiang.bi...@zte.com.cn 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. :) Thanks! Regards, Jiang