From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46464)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bPmgM-0005zT-56
	for qemu-devel@nongnu.org; Wed, 20 Jul 2016 04:16:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bPmgH-00009n-SS
	for qemu-devel@nongnu.org; Wed, 20 Jul 2016 04:16:41 -0400
Date: Wed, 20 Jul 2016 04:16:28 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <1514501603.8803202.1469002588620.JavaMail.zimbra@redhat.com>
In-Reply-To: <20160720073836.GF10539@ad.usersys.redhat.com>
References: <1468901281-22858-1-git-send-email-eblake@redhat.com>
	<578E4708.5080308@redhat.com>
	<aad94967-fd7b-4377-ad40-3f07d67b5c32@redhat.com>
	<20160720033402.GA7641@ad.usersys.redhat.com>
	<578EF446.70202@redhat.com>
	<20160720043709.GA10539@ad.usersys.redhat.com>
	<913397c9-6edc-2561-3d2e-e32032f9db22@redhat.com>
	<20160720073836.GF10539@ad.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v5 13/14] nbd: Implement
 NBD_CMD_WRITE_ZEROES on server
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: Fam Zheng <famz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>, Kevin Wolf <kwolf@redhat.com>, nbd-general@lists.sourceforge.net, qemu-block@nongnu.org, qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>

> On Wed, 07/20 09:09, Paolo Bonzini wrote:
> > On 20/07/2016 06:37, Fam Zheng wrote:
> > > 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.)
> > 
> > Apparently it's because it's zeroed.
> > 
> > $ fallocate -z -o 10485760 -l 10485760 test
> > $ fallocate -p -o 49152000 -l 10485760 test
> > $ fallocate -o 49152000 -l 10485760 test
> > $ fallocate -p -o 65536000 -l 10485760 test
> > 
> > Now we have:
> > 
> > - a zero area at 10240K..20480K
> > 
> > - an hole+allocated area at 48000K..59240K
> > 
> > - a hole at 64000K..74240K
> > 
> > $ qemu-img map test
> > Offset          Length          Mapped to       File
> > 0               0xa00000        0               test    << ends at 10240K
> > 0x1400000       0x1ae0000       0x1400000       test    << ends at 48000K
> > 0x38e0000       0x5a0000        0x38e0000       test    << ends at 64000K
> > 0x4880000       0x1b80000       0x4880000       test
> 
> Hah? I'm apparently missing something. I can't see these entries:
> 
> > fam@ad:/var/tmp$ cat /tmp/sh
> > touch test
> > fallocate -z -o 10485760 -l 10485760 test
> > fallocate -p -o 49152000 -l 10485760 test
> > fallocate -o 49152000 -l 10485760 test
> > fallocate -p -o 65536000 -l 10485760 test
> > qemu-img map test
> > fam@ad:/var/tmp$ sh /tmp/sh
> > Offset          Length          Mapped to       File
> 
> (I'm using Fedora 24 but I've also tried RHEL 7.)

That was after a full allocation of a 1GB file.  I didn't copy that line
because I had the file lying around from another day--sorry.

Paolo