From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XykN5-0006Qv-73 for qemu-devel@nongnu.org; Wed, 10 Dec 2014 11:44:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XykN0-0005Gg-AB for qemu-devel@nongnu.org; Wed, 10 Dec 2014 11:44:15 -0500 Message-ID: <54887851.20600@redhat.com> Date: Wed, 10 Dec 2014 17:44:01 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1417796112-15141-1-git-send-email-ming.lei@canonical.com> <5481DE62.4000206@redhat.com> <5487351C.9020706@redhat.com> <548818BC.4050905@redhat.com> <548842B5.9090009@redhat.com> <54886078.1090503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] block: fix big write List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Kevin Wolf , qemu-stable@nongnu.org, Stefan Hajnoczi , qemu-devel On 10/12/2014 16:47, Ming Lei wrote: > > > Finally blkdev_issue_zeroout() can send WRITE SAME(10/16) directly > > > and it can be from user space, fs, and block drivers. > > > > That is WRITE SAME without UNMAP, it is not used by mkfs, and Linux has > > always honored max_write_same_blocks for it (defaulting to a 65535 block > > limit for older devices that did not report a limit). > > From QEMU view, blk_aio_write_zeroes() still need to handle > case without UNMAP, and the default 65535 is just linux's current > implementation, and even the recent patch tries to increase > the default setting. Also the default limit might be bigger on other OS. What is "another OS" that produces WRITE SAME with >2GB of data? http://blogs.vmware.com/vsphere/2012/06/low-level-vaai-behaviour.html#more-3129 says ESX's default write same size is 1MB (2048 blocks). Windows does not use WRITE SAME at all, according to Microsoft at http://msdn.microsoft.com/en-us/library/windows/hardware/dn265487%28v=vs.85%29.aspx. 65535 is a sensible default for a host that doesn't know about max_write_same_sectors. Anything else would break physical drives as well. Please produce a concrete case that is broken, with a released OS. Paolo > > So what *concrete* case would be fixed by adding extra little-used code > > in QEMU to do the split?