From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xyhcf-00068q-4N for qemu-devel@nongnu.org; Wed, 10 Dec 2014 08:48:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyhcZ-00062E-0y for qemu-devel@nongnu.org; Wed, 10 Dec 2014 08:48:09 -0500 Message-ID: <548842B5.9090009@redhat.com> Date: Wed, 10 Dec 2014 13:55:17 +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> 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 13:23, Ming Lei wrote: >> > >> > Again, we're talking of 2GB and this is something that should never >> > happen in practice. > Again, the 2GB limit can be avoided if I/O is splitted, isn't it? Sure. The guest kernel is doing the split. > It is _not_ never happen at all, and easy to be triggered when using > mkfs. mkfs is not something to optimize for, it's just something that should work. (Also, some hardware may time out if you do write same with too high a block count). Both Linux and Windows will always use UNMAP on QEMU, except for the small time period where Linux used WRITE SAME and this bug was discovered. And all versions of Linux that used WRITE SAME honored the max_ws_blocks field. Paolo