[Top][All Lists]
[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/