From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgWun-0006mf-RK for qemu-devel@nongnu.org; Wed, 13 Nov 2013 04:39:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgWuf-000500-5O for qemu-devel@nongnu.org; Wed, 13 Nov 2013 04:39:13 -0500 Received: from mail-ee0-x235.google.com ([2a00:1450:4013:c00::235]:64863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgWue-0004zv-US for qemu-devel@nongnu.org; Wed, 13 Nov 2013 04:39:05 -0500 Received: by mail-ee0-f53.google.com with SMTP id b57so45221eek.40 for ; Wed, 13 Nov 2013 01:39:04 -0800 (PST) Sender: Paolo Bonzini Message-ID: <528348B2.6030202@redhat.com> Date: Wed, 13 Nov 2013 10:38:58 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1384271389-20716-1-git-send-email-pbonzini@redhat.com> <1384271389-20716-7-git-send-email-pbonzini@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/11] scsi-disk: correctly implement WRITE SAME List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Il 13/11/2013 07:18, Peter Lieven ha scritto: >> > The WRITE SAME command is implemented incorrectly. WRITE SAME with the >> > UNMAP bit set should _not_ unmap the sectors unless the written data >> > matches the payload of the WRITE SAME command; currently, QEMU is not >> > looking at the payload at all. >> > >> > Thus, fetch the data to be written from the input buffer. If it is >> > all zeroes, we can use the write_zeroes call (possibly with the new >> > MAY_UNMAP flag). Otherwise, do as many write cycles as needed, covering >> > 512k at a time to avoid allocating lots of memory for the bounce >> > buffer. > > Would it make sense to add a bdrv_write_same or is the use case for > WRITE SAME with non-zero payload too rare? It would, but it is definitely very rare, probably so much that we need not care. Linux only invokes it for zero payloads. Also, for zero payload there are additional benefits. First, supporting WRITE SAME with UNMAP if the host has LBPRZ=1 or analogous. Second, using zero clusters in qcow2/qed/vmdk. > And secondly would it make sense to add an optimal request size field > to the BlockLimits? The optimal request size is not particularly useful if it is not visible to the guest, unfortunately. But we cannot pass values arbitrarily to the guest because they would change if the backing storage changed (e.g. from NFS to local, or from raw to qcow2). So I'm not sure who would actually use the optimal request size. Paolo