Re: Which qemu change corresponds to RedHat bug 1655408

[Max Reitz <mreitz@redhat.com>]

On 10.10.20 00:54, Jakob Bohm wrote:

[...]

> Theoretically, locking on a raw file needs to be protocol-compatible
> with loop-mounting the same raw file, so if the loop driver doesn't
> probe those magic byte offsets to prevent out-of-order block writes,
> then there is little point for the qemu raw driver to do so.
> 
> This applies to both the loop driver in the host kernel and the loop
> driver on any other machine with file share access to the sane image
> file.

The file access locks aren’t meant to prevent arbitrary other programs
from accessing those specific few bytes, but to prevent concurrently
running qemu processes from accessing the image.  That’s why qemu
doesn’t lock the whole image file, but only a small and very specific
set of bytes.

The problem we originally faced was that some people would run qemu-img
to modify qcow2 images while a VM was running, leading to metadata
corruption and thus data loss.  This is the main reason the locks were
introduced.  However, the problem isn’t limited to qcow2 images.  Even
for raw images, we generally have to prevent e.g. concurrent writes to
the image (from other VMs that might want to use that image) because the
guest won’t be able to deal with that.  Hence why we take locks even on
non-qcow2 images.

> As for upgrading, I will try newer kernels packaged for the Debian
> version used, once the current large batch job has completed, but I
> doubt it will make much difference given the principles I just stated.

I’m not sure whether I understood your paragraphs above wrong, but I
don’t see how they explain why the bug would appear (i.e., why qemu
would fail taking the file lock).  It only seems to explain why it seems
superfluous for qemu to take locks when the loop driver will be the only
concurrent user of the image (presumably because the loop driver just
doesn’t take any locks; which means that qemu should be able to).

Max