Control: fixed -1 1:2.10.0-1

05.12.2019 18:35, Michael Tokarev wrote:
Control: fixed -1 1:3.1+dfsg-8+deb10u3

Actually this is fixed by this commit:

commit c61e684e44272f2acb2bef34cf2aa234582a73a9
Author: Eric Blake <ebl...@redhat.com>
Date:   Thu May 4 21:15:00 2017 -0500

    block: Exploit BDRV_BLOCK_EOF for larger zero blocks

    When we have a BDS with unallocated clusters, but asking the status
    of its underlying bs->file or backing layer encounters an end-of-file
    condition, we know that the rest of the unallocated area will read as
    zeroes.  However, pre-patch, this required two separate calls to
    bdrv_get_block_status(), as the first call stops at the point where
    the underlying file ends.  Thanks to BDRV_BLOCK_EOF, we can now widen
    the results of the primary status if the secondary status already
    includes BDRV_BLOCK_ZERO.

    In turn, this fixes a TODO mentioned in iotest 154, where we can now
    see that all sectors in a partial cluster at the end of a file read
    as zero when coupling the shorter backing file's status along with our
    knowledge that the remaining sectors came from an unallocated cluster.

    Also, note that the loop in bdrv_co_get_block_status_above() had an
    inefficent exit: in cases where the active layer sets BDRV_BLOCK_ZERO
    but does NOT set BDRV_BLOCK_ALLOCATED (namely, where we know we read
    zeroes merely because our unallocated clusters lie beyond the backing
    file's shorter length), we still ended up probing the backing layer
    even though we already had a good answer.

Which went into qemu 2.10.

However, backporting it to 2.8 requires a bit more of background,
i/o subsystem has been modified significantly between 2.8 and 2.10.

Thanks,

/mjt

Reply via email to