From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50968)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XHB4W-0006ZW-Ga
	for qemu-devel@nongnu.org; Tue, 12 Aug 2014 08:21:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XHB4P-0005nV-Nn
	for qemu-devel@nongnu.org; Tue, 12 Aug 2014 08:21:00 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39934)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1XHB4P-0005lp-Ew
	for qemu-devel@nongnu.org; Tue, 12 Aug 2014 08:20:53 -0400
Date: Tue, 12 Aug 2014 20:21:06 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20140812122106.GD2803@T430.redhat.com>
References: <CABPa+v3e1ZGyD9higvQmk6H-3A8YWohG-AhQY0bcCPJtjbtAtg@mail.gmail.com>
	<20140812005214.GB6226@T430.nay.redhat.com>
	<CABPa+v1pjVfNk-gyeARX8+K3S9+SZ4ZrediD7bD3-apTqmxKjQ@mail.gmail.com>
	<20140812111919.GA2803@T430.redhat.com>
	<CABPa+v1a7meoEtjLkwygjuZEABTqd8q3efGWJvAsAr-mLTQb-A@mail.gmail.com>
	<20140812113916.GB2803@T430.redhat.com>
	<CABPa+v0VbUCTTrgzBAnj4zBysgN0OZjb9hupSrQ1bhHigxC4-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABPa+v0VbUCTTrgzBAnj4zBysgN0OZjb9hupSrQ1bhHigxC4-Q@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] disk image: self-organized format or raw file
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: =?utf-8?B?5ZC05YW05Y2a?= <wuxb45@gmail.com>
Cc: qemu-devel@nongnu.org

On Tue, 08/12 08:03, =E5=90=B4=E5=85=B4=E5=8D=9A wrote:
> I carefully read your reply and thought of it carefully. I'm sorry that
> when I said "I get it" I actually meant "I believe you" but not "I
> understand it".
> The problem would not come from cp or rsync -- It's not their fault. Th=
ey
> just have no way to make it right.
> The real reason of it would be that filesystems have different allocati=
on
> unit size.
>=20
> For example, a file is of 16KB in appearance, and the 4KB-12KB of it is=
 a
> hole (0KB-4KB and 12KB-16KB has valid data).
> The FS held it has 4KB block size, so it *could* be allocated like this.
> Copying this file to a filesystem of 16KB block size would cause the en=
tire
> 16KB filled with data, to be specific, the hole is filled with zero and
> cp/rsync have NO way to make difference.
>=20
> That's not a engineering issue of cp/rsync. It's a real issue cause by =
the
> fact that (most) filesystems have configurable block size.
>=20

Correct.

It's not an fault of any party, because there is no contract on this part=
 at
all. What you suggested is not a good use case of the file system hole.

Fam