[PATCH 0/3] fix potential data loss in QEMU (missed flush)

Denis V. Lunev via posted 3 patches 1 month, 1 week ago
Failed in applying to current master (apply log)
[PATCH 0/3] fix potential data loss in QEMU (missed flush)
Posted by Denis V. Lunev via 1 month, 1 week ago
This series is a followup to my previous patch sent under
"qcow2: add very final sync on QCOW2 image closing". Could be considered
as v2.

This series addresses two problems:
1. bdrv_co_flush() at the end of bdrv_driver_pwritev() and
   bdrv_co_do_pwrite_zeroes() could be effectively no op. The problem is
   that bdrv_co_flush() is optimized internally this way to track real
   requests which were making changes in the image and without such
   requests from previous flush() do nothing. Requests are tracked using
   write_gen on BDS. This field should be incremented after write is
   completed but before flush is called.

   This could be considered as potential data loss if caller relies on
   BDRV_REQ_FUA flag which means that such requests are really lands on
   the underlying device, which could not due to missed flush().

2. qcow2_update_header() must actually write header with BDRV_REQ_FUA
   flag as image processing on open relies on the fact that header is
   actual and it is not possible to reorder header modifications and
   image content modifications.

Changes:
    * added patches 1 & 2

Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
Re: [PATCH 0/3] fix potential data loss in QEMU (missed flush)
Posted by Denis V. Lunev 1 week, 6 days ago
On 12/29/25 17:07, Denis V. Lunev wrote:
> This series is a followup to my previous patch sent under
> "qcow2: add very final sync on QCOW2 image closing". Could be considered
> as v2.
>
> This series addresses two problems:
> 1. bdrv_co_flush() at the end of bdrv_driver_pwritev() and
>    bdrv_co_do_pwrite_zeroes() could be effectively no op. The problem is
>    that bdrv_co_flush() is optimized internally this way to track real
>    requests which were making changes in the image and without such
>    requests from previous flush() do nothing. Requests are tracked using
>    write_gen on BDS. This field should be incremented after write is
>    completed but before flush is called.
>
>    This could be considered as potential data loss if caller relies on
>    BDRV_REQ_FUA flag which means that such requests are really lands on
>    the underlying device, which could not due to missed flush().
>
> 2. qcow2_update_header() must actually write header with BDRV_REQ_FUA
>    flag as image processing on open relies on the fact that header is
>    actual and it is not possible to reorder header modifications and
>    image content modifications.
>
> Changes:
>     * added patches 1 & 2
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> CC: Kevin Wolf <kwolf@redhat.com>
> CC: Hanna Reitz <hreitz@redhat.com>
>
ping
Re: [PATCH 0/3] fix potential data loss in QEMU (missed flush)
Posted by Denis V. Lunev 2 weeks, 6 days ago
On 12/29/25 17:07, Denis V. Lunev wrote:
> This series is a followup to my previous patch sent under
> "qcow2: add very final sync on QCOW2 image closing". Could be considered
> as v2.
>
> This series addresses two problems:
> 1. bdrv_co_flush() at the end of bdrv_driver_pwritev() and
>    bdrv_co_do_pwrite_zeroes() could be effectively no op. The problem is
>    that bdrv_co_flush() is optimized internally this way to track real
>    requests which were making changes in the image and without such
>    requests from previous flush() do nothing. Requests are tracked using
>    write_gen on BDS. This field should be incremented after write is
>    completed but before flush is called.
>
>    This could be considered as potential data loss if caller relies on
>    BDRV_REQ_FUA flag which means that such requests are really lands on
>    the underlying device, which could not due to missed flush().
>
> 2. qcow2_update_header() must actually write header with BDRV_REQ_FUA
>    flag as image processing on open relies on the fact that header is
>    actual and it is not possible to reorder header modifications and
>    image content modifications.
>
> Changes:
>     * added patches 1 & 2
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> CC: Kevin Wolf <kwolf@redhat.com>
> CC: Hanna Reitz <hreitz@redhat.com>
>
ping
Re: [PATCH 0/3] fix potential data loss in QEMU (missed flush)
Posted by Denis V. Lunev 3 weeks, 5 days ago
On 12/29/25 17:07, Denis V. Lunev wrote:
> This series is a followup to my previous patch sent under
> "qcow2: add very final sync on QCOW2 image closing". Could be considered
> as v2.
>
> This series addresses two problems:
> 1. bdrv_co_flush() at the end of bdrv_driver_pwritev() and
>    bdrv_co_do_pwrite_zeroes() could be effectively no op. The problem is
>    that bdrv_co_flush() is optimized internally this way to track real
>    requests which were making changes in the image and without such
>    requests from previous flush() do nothing. Requests are tracked using
>    write_gen on BDS. This field should be incremented after write is
>    completed but before flush is called.
>
>    This could be considered as potential data loss if caller relies on
>    BDRV_REQ_FUA flag which means that such requests are really lands on
>    the underlying device, which could not due to missed flush().
>
> 2. qcow2_update_header() must actually write header with BDRV_REQ_FUA
>    flag as image processing on open relies on the fact that header is
>    actual and it is not possible to reorder header modifications and
>    image content modifications.
>
> Changes:
>     * added patches 1 & 2
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> CC: Kevin Wolf <kwolf@redhat.com>
> CC: Hanna Reitz <hreitz@redhat.com>
>
ping