From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPjG5-0001Lx-RR for qemu-devel@nongnu.org; Wed, 20 Jul 2016 00:37:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPjG3-000054-S1 for qemu-devel@nongnu.org; Wed, 20 Jul 2016 00:37:20 -0400 Date: Wed, 20 Jul 2016 12:37:09 +0800 From: Fam Zheng Message-ID: <20160720043709.GA10539@ad.usersys.redhat.com> References: <1468901281-22858-1-git-send-email-eblake@redhat.com> <1468901281-22858-14-git-send-email-eblake@redhat.com> <20160719062131.GG18103@ad.usersys.redhat.com> <578E4708.5080308@redhat.com> <20160720033402.GA7641@ad.usersys.redhat.com> <578EF446.70202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <578EF446.70202@redhat.com> Subject: Re: [Qemu-devel] [PATCH v5 13/14] nbd: Implement NBD_CMD_WRITE_ZEROES on server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Paolo Bonzini , Kevin Wolf , "nbd-general@lists.sourceforge.net" , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz On Tue, 07/19 21:47, Eric Blake wrote: > > In block/raw-posix.c:handle_aiocb_write_zeroes(): > >> #ifdef CONFIG_FALLOCATE_PUNCH_HOLE > >> if (s->has_discard && s->has_fallocate) { > >> int ret = do_fallocate(s->fd, > >> FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > >> aiocb->aio_offset, aiocb->aio_nbytes); > >> if (ret == 0) { > >> ret = do_fallocate(s->fd, 0, aiocb->aio_offset, aiocb->aio_nbytes); > > That is just implementation: punch a hole, BUT THEN reallocate it back, > so that in the end, the file is still not sparse in that region. Or am > I reading it wrong? Yes, you are right about this, I was confused because "qemu-img map" does not report this allocation state after zero write. (No idea why SEEK_DATA doesn't hit the fallocate'ed area.) Then, when it comes to qcow2, it's a bit different: after a NO_HOLE write zero doesn't allocate anything, it only sets the bit in cluster table. In other words, NO_HOLE only ensures allocated clusters are not deallocated, but it doesn't ensure the population of previously unallocated area. Is that intended? Fam