From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz0Rv-0002bV-9C for qemu-devel@nongnu.org; Tue, 25 Oct 2016 08:03:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz0Rq-0007jH-EX for qemu-devel@nongnu.org; Tue, 25 Oct 2016 08:03:23 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:50446 helo=mx01.kamp.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bz0Rq-0007i3-4q for qemu-devel@nongnu.org; Tue, 25 Oct 2016 08:03:18 -0400 References: <1469129688-22848-1-git-send-email-eblake@redhat.com> <1469129688-22848-5-git-send-email-eblake@redhat.com> <20160727072543.GF23258@ad.usersys.redhat.com> <5799704D.9060408@redhat.com> <18c31752-8399-1763-a42e-c2b924920b55@redhat.com> From: Peter Lieven Message-ID: <12c8e895-f8ab-825f-82e7-4a2c8cc22de5@kamp.de> Date: Tue, 25 Oct 2016 14:03:13 +0200 MIME-Version: 1.0 In-Reply-To: <18c31752-8399-1763-a42e-c2b924920b55@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] block: Cater to iscsi with non-power-of-2 discard List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Eric Blake , Fam Zheng Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Stefan Hajnoczi , Kevin Wolf , Max Reitz Am 01.08.2016 um 11:22 schrieb Paolo Bonzini: > > On 28/07/2016 04:39, Eric Blake wrote: >> On 07/27/2016 01:25 AM, Fam Zheng wrote: >>> On Thu, 07/21 13:34, Eric Blake wrote: >>>> + max_write_zeroes = max_write_zeroes / alignment * alignment; >>> Not using QEMU_ALIGN_DOWN despite patch 3? >> Looks like I missed that on the rebase. Can fix if there is a reason for >> a respin. > Since Stefan acked this, I'm applying the patch and fixing it to use > QEMU_ALIGN_DOWN. > > Paolo Hi, I came across a sort of regression we introduced with the dropping of head and tail of an unaligned discard. The discard alignment that we use to trim the discard request is just a hint. I learned on the equallogics that a page (which is this unusal 15MB large) is unallocated even if the discard happens in pieces. E.g. in slices of 1MB requests. From my point of view I would like to restore the old behaviour. What do you think? Thanks, Peter