qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in A


From: Stefan Priebe - Profihost AG
Subject: Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands
Date: Mon, 19 Nov 2012 14:01:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2

Am 19.11.2012 13:24, schrieb Paolo Bonzini:
Il 19/11/2012 12:49, Stefan Priebe - Profihost AG ha scritto:

It still causes hangs no?  Though it works apart from that.

iscsi/libiscsi and discards works fine since your latest patches:
1bd075f29ea6d11853475c7c42734595720c3ac6
cfb3f5064af2d2e29c976e292c9472dfe9d61e31
27cbd828c617944c0f9603763fdf4fa87e7ad923
b20909195745c34a819aed14ae996b60ab0f591f

Does the console still hang though?

No everything is absolutely fine.

But in rbd it starts to cancel the discard requests. Both using the same
guest and host kernel with the same QEMU version.

rbd's cancellation is broken like libiscsi's was.  So the cancellation
succeeds apparently, but it is subject to the same race introduced in
commit 64e69e8 (iscsi: Fix NULL dereferences / races between task
completion and abort, 2012-08-15) for libiscsi.

It risks corruption in case the following happens:

         guest                  qemu                 rbd server
=========================================================================
         send write 1 -------->
                                send write 1 ------>
         cancel write 1 ------>
                                cancel write 1 ---->
            <------------------ cancelled
         send write 2 -------->
                                send write 2 ------>
                                    <--------------- completed write 2
            <------------------ completed write 2
                                    <--------------- completed write 1

Here, the guest would see write 2 superseding write 1, when in fact the
outcome could have been the opposite.  The right behavior is to return
only after the target says whether the cancellation was done or not.
For libiscsi, it was implemented by the commits you mention.

So the whole bunch of changes is needed for rbd? Or just 64e69e8? Or all mentioned except 64e69e8 as 64e69e8 introduced the problem?

Stefan



reply via email to

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