From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaQOl-0008Np-7q for qemu-devel@nongnu.org; Mon, 19 Nov 2012 07:24:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TaQOi-0005YZ-5h for qemu-devel@nongnu.org; Mon, 19 Nov 2012 07:24:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaQOh-0005YS-T8 for qemu-devel@nongnu.org; Mon, 19 Nov 2012 07:24:20 -0500 Message-ID: <50AA24E7.7010009@redhat.com> Date: Mon, 19 Nov 2012 13:24:07 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <589082222.7272963.1352241778123.JavaMail.root@redhat.com> <50A95A6A.4010109@profihost.ag> <50A9E991.2070609@redhat.com> <50A9FD86.3050400@profihost.ag> <50AA01C0.8030709@redhat.com> <50AA0314.6090208@profihost.ag> <50AA04A7.4080200@redhat.com> <50AA065F.5010602@profihost.ag> <50AA089B.7010400@redhat.com> <50AA0A2E.2090506@profihost.ag> <50AA0B90.6060702@redhat.com> <50AA1085.6000106@profihost.ag> <50AA151A.7030008@redhat.com> <50AA1CE7.7090100@profihost.ag> In-Reply-To: <50AA1CE7.7090100@profihost.ag> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] scsi-hd with discard_granularity and unmap results in Aborted Commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Priebe - Profihost AG Cc: josh.durgin@inktank.com, qemu-devel@nongnu.org, sage@newdream.net 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? > 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. Paolo