From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y81gR-00028a-91 for qemu-devel@nongnu.org; Mon, 05 Jan 2015 02:02:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y81gO-0003Iu-2k for qemu-devel@nongnu.org; Mon, 05 Jan 2015 02:02:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y81gN-0003IZ-RJ for qemu-devel@nongnu.org; Mon, 05 Jan 2015 02:02:32 -0500 Date: Mon, 5 Jan 2015 15:02:23 +0800 From: Fam Zheng Message-ID: <20150105070223.GC1800@ad.nay.redhat.com> References: <1419931250-19259-1-git-send-email-den@openvz.org> <1419931250-19259-7-git-send-email-den@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1419931250-19259-7-git-send-email-den@openvz.org> Subject: Re: [Qemu-devel] [PATCH 6/8] block: use fallocate(FALLOC_FL_PUNCH_HOLE) & fallocate(0) to write zeroes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: Kevin Wolf , Peter Lieven , qemu-devel@nongnu.org, Stefan Hajnoczi On Tue, 12/30 12:20, Denis V. Lunev wrote: > This sequence works efficiently if FALLOC_FL_ZERO_RANGE is not supported. > > Simple fallocate(0) will extend file with zeroes when appropriate in the > middle of the file if there is a hole there and at the end of the file. > Unfortunately fallocate(0) does not drop the content of the file if > there is a data on this offset. Therefore to make the situation consistent > we should drop the data beforehand. This is done using FALLOC_FL_PUNCH_HOLE > > This should increase the performance a bit for not-so-modern kernels or for > filesystems which do not support FALLOC_FL_ZERO_RANGE. > > Signed-off-by: Denis V. Lunev > CC: Kevin Wolf > CC: Stefan Hajnoczi > CC: Peter Lieven > --- > block/raw-posix.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/block/raw-posix.c b/block/raw-posix.c > index 7866d31..96a8678 100644 > --- a/block/raw-posix.c > +++ b/block/raw-posix.c > @@ -968,6 +968,23 @@ static ssize_t handle_aiocb_write_zeroes(RawPosixAIOData *aiocb) > #endif > > s->has_write_zeroes = false; > + > +#ifdef CONFIG_FALLOCATE_PUNCH_HOLE > + if (s->has_discard) { > + int ret; > + ret = do_fallocate(s->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > + aiocb->aio_offset, aiocb->aio_nbytes); > + if (ret < 0) { > + if (ret == -ENOTSUP) { > + s->has_discard = false; > + } > + return ret; > + } > + return do_fallocate(s->fd, 0, aiocb->aio_offset, aiocb->aio_nbytes); Why is fallocate(0) necessary here? The manpage says: Deallocating file space Specifying the FALLOC_FL_PUNCH_HOLE flag (available since Linux 2.6.38) in mode deallocates space (i.e., creates a hole) in the byte range starting at offset and continuing for len bytes. Within the specified range, partial file system blocks are zeroed, and whole file system blocks are removed from the file. After a successful call, subsequent reads from this range will return zeroes. So the data are already zeroes after FALLOC_FL_PUNCH_HOLE. Fam > + } > +#endif > + > + s->has_discard = false; > return -ENOTSUP; > } > > -- > 1.9.1 > >