qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: KVM call agenda for Jan 25


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25
Date: Mon, 28 Feb 2011 08:36:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Stefan Hajnoczi <address@hidden> writes:

> On Sat, Feb 26, 2011 at 9:50 PM, Dushyant Bansal
> <address@hidden> wrote:
>> Disk block size is usually 512 bytes and in qemu-img, sector size is also
>> 512B. And, this change would  copy n sectors even if only one of them
>> actually contains data (while cp checks and copies one block(=sector) at a
>> time). Therefore, it will end up writing more data than cp.
>
> cp(1) from GNU coreutils 8.5 works in units of 32 KB on my system.  It
> reads 32 KB and checks for all zeroes.  If there are all zeroes, it
> seeks ahead 32 KB in the output file.  Otherwise it writes the entire
> 32 KB.

The latest version[*] of cp does better:

    cp now copies sparse files efficiently on file systems with FIEMAP
    support (ext4, btrfs, xfs, ocfs2).  Before, it had to read 2^20 bytes
    when copying a 1MiB sparse file.  Now, it copies bytes only for the
    non-sparse sections of a file.  Similarly, to induce a hole in the
    output file, it had to detect a long sequence of zero bytes.  Now,
    it knows precisely where each hole in an input file is, and can
    reproduce them efficiently in the output file.  mv also benefits
    when it resorts to copying, e.g., between file systems.

But beware of kernel bugs[**].

> You can check what cp(1) is doing using strace(1).

Often enlightening :)

[...]

[*] http://lists.gnu.org/archive/html/coreutils-announce/2011-02/msg00000.html

[**] http://lwn.net/Articles/429345/
Subscribera-only, should become public soon.  In the meantime, try
http://lwn.net/Articles/429349/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]