From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46000)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wuxb45@gmail.com>) id 1XHAo5-00021q-Ib
	for qemu-devel@nongnu.org; Tue, 12 Aug 2014 08:04:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <wuxb45@gmail.com>) id 1XHAo3-0007dS-7k
	for qemu-devel@nongnu.org; Tue, 12 Aug 2014 08:04:01 -0400
Received: from mail-ig0-x235.google.com ([2607:f8b0:4001:c05::235]:35367)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <wuxb45@gmail.com>) id 1XHAo3-0007dA-2n
	for qemu-devel@nongnu.org; Tue, 12 Aug 2014 08:03:59 -0400
Received: by mail-ig0-f181.google.com with SMTP id h3so6421869igd.14
	for <qemu-devel@nongnu.org>; Tue, 12 Aug 2014 05:03:58 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20140812113916.GB2803@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>
From: =?UTF-8?B?5ZC05YW05Y2a?= <wuxb45@gmail.com>
Date: Tue, 12 Aug 2014 08:03:18 -0400
Message-ID: <CABPa+v0VbUCTTrgzBAnj4zBysgN0OZjb9hupSrQ1bhHigxC4-Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary=047d7b1118fd6bf08f05006d771f
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: Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org

--047d7b1118fd6bf08f05006d771f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. They
just have no way to make it right.
The real reason of it would be that filesystems have different allocation
unit size.

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 entire
16KB filled with data, to be specific, the hole is filled with zero and
cp/rsync have NO way to make difference.

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.

Is that correct?
I really appreciate.


Cheers!
       =E5=90=B4=E5=85=B4=E5=8D=9A  Wu, Xingbo <wuxb45@gmail.com>


On Tue, Aug 12, 2014 at 7:39 AM, Fam Zheng <famz@redhat.com> wrote:

> On Tue, 08/12 07:22, =E5=90=B4=E5=85=B4=E5=8D=9A wrote:
> > Thanks, I get it.
> > Does rsync have exactly the same problem?
>
> Yes.
>
> Fam
>

--047d7b1118fd6bf08f05006d771f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I carefully read your reply and thought of it carefully. I=
&#39;m sorry that when I said &quot;I get it&quot; I actually meant &quot;I=
 believe you&quot; but not &quot;I understand it&quot;.<div>The problem wou=
ld not come from cp or rsync -- It&#39;s not their fault. They just have no=
 way to make it right.</div>

<div>The real reason of it would be that filesystems have different allocat=
ion unit size.</div><div><br></div><div>For example, a file is of 16KB in a=
ppearance, and the 4KB-12KB of it is a hole (0KB-4KB and 12KB-16KB has vali=
d data).</div>

<div>The FS held it has 4KB block size, so it *could* be allocated like thi=
s.</div><div>Copying this file to a filesystem of 16KB block size would cau=
se the entire 16KB filled with data, to be specific, the hole is filled wit=
h zero and cp/rsync have NO way to make difference.</div>

<div><br></div><div>That&#39;s not a engineering issue of cp/rsync. It&#39;=
s a real issue cause by the fact that (most) filesystems have configurable =
block size.</div><div><br></div><div>Is that correct?<br></div><div>I reall=
y appreciate.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><b=
r>Cheers!<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E5=90=B4=E5=85=B4=E5=8D=9A =C2=A0W=
u, Xingbo &lt;<a href=3D"mailto:wuxb45@gmail.com" target=3D"_blank">wuxb45@=
gmail.com</a>&gt;<br></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Aug 12, 2014 at 7:39 AM, Fam Zhe=
ng <span dir=3D"ltr">&lt;<a href=3D"mailto:famz@redhat.com" target=3D"_blan=
k">famz@redhat.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"">On Tue, 08/12 07:22, =E5=90=B4=E5=85=B4=E5=8D=9A wrote:<br>
&gt; Thanks, I get it.<br>
&gt; Does rsync have exactly the same problem?<br>
<br>
</div>Yes.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Fam<br>
</font></span></blockquote></div><br></div>

--047d7b1118fd6bf08f05006d771f--