From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:33613)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1SBSsH-0006Ql-Du
	for qemu-devel@nongnu.org; Sat, 24 Mar 2012 11:27:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1SBSsF-0005ih-VH
	for qemu-devel@nongnu.org; Sat, 24 Mar 2012 11:27:24 -0400
Received: from verein.lst.de ([213.95.11.211]:52350 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1SBSsF-0005iV-Of
	for qemu-devel@nongnu.org; Sat, 24 Mar 2012 11:27:23 -0400
Date: Sat, 24 Mar 2012 16:27:21 +0100
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20120324152721.GA13014@lst.de>
References: <1331226917-6658-1-git-send-email-pbonzini@redhat.com>
	<1331226917-6658-7-git-send-email-pbonzini@redhat.com>
	<4F5A31B2.3050701@redhat.com> <4F5A46A1.4000508@redhat.com>
	<1331402560.8577.46.camel@watermelon.coderich.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1331402560.8577.46.camel@watermelon.coderich.net>
Subject: Re: [Qemu-devel] [RFC PATCH 06/17] block: use bdrv_{co,
	aio}_discard for write_zeroes operations
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Laager <rlaager@wiktel.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org

On Sat, Mar 10, 2012 at 12:02:40PM -0600, Richard Laager wrote:
> If we could probe for FALLOC_FL_PUNCH_HOLE support, then we could avoid
> advertising discard support based on FALLOC_FL_PUNCH_HOLE when it is not
> going to work. This would side step these problems. You said it wasn't
> possible to probe for FALLOC_FL_PUNCH_HOLE. Have you considered probing
> by extending the file by one byte and then punching that:
>         char buf = 0;
>         fstat(s->fd, &st);
>         pwrite(s->fd, &buf, 1, st.st_size + 1);
>         has_discard = !fallocate(s->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,

There is no point in using FALLOC_FL_KEEP_SIZE together with
FALLOC_FL_PUNCH_HOLE.