From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sul14-00051Z-M2 for qemu-devel@nongnu.org; Fri, 27 Jul 2012 09:55:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sul0y-0006sQ-JK for qemu-devel@nongnu.org; Fri, 27 Jul 2012 09:55:42 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:52391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sul0y-0006rk-D3 for qemu-devel@nongnu.org; Fri, 27 Jul 2012 09:55:36 -0400 Received: by pbbro12 with SMTP id ro12so4896752pbb.4 for ; Fri, 27 Jul 2012 06:55:35 -0700 (PDT) From: Anthony Liguori In-Reply-To: <1343318389-28877-1-git-send-email-rjones@redhat.com> References: <1343318389-28877-1-git-send-email-rjones@redhat.com> Date: Fri, 27 Jul 2012 08:55:31 -0500 Message-ID: <87wr1p8g18.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] Detect zero writes (for discussion only, not to be applied) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" , qemu-devel@nongnu.org Cc: kwolf@redhat.com "Richard W.M. Jones" writes: > [Applies against qemu 1.1.0, not HEAD, because qemu from git seems to > be broken at the moment. But the patch is easy to rebase.] How's it broken? Regards, Anthony Liguori > This patch adds a -drive detect_zero=on|off flag (defaults to "off"). > > Setting this on causes the write path to detect all zero byte writes > and, for block device drivers which support this, turn the request > into the more space-efficient bdrv_co_do_write_zeroes call. > > The use case is for virt-sparsify. We want to create an intermediate > qcow2 overlay file which we know will mostly contain zeroes, and we > want qcow2 to handle this without creating a huge empty file. In my > testing, the size of the intermediate file is reduced considerably > (down to about 1/4 of the original size), making sparsification of > large mostly-empty guests possible for the first time. > > The implementation is very simple-minded. It tests if the entire > request is all zero bytes or not. A better implementation would > almost certainly be even more space-efficient, but at the cost of > splitting some write requests (if that's a problem). > > Testing: I booted and tested an F16 guest with this patch and the > setting "on", without problems. I also modified libguestfs to add > this flag, then ran the whole libguestfs test suite with no reported > problems. > > Rich.