qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] disk image: self-organized format or raw file


From: 吴兴博
Subject: Re: [Qemu-devel] disk image: self-organized format or raw file
Date: Tue, 12 Aug 2014 09:45:29 -0400

Thanks for your information. It's really helpful.
I think adding a bitmap alongside the raw file ( or just within that file) would be suffice to distinguish between present or in backing file.
The idea in FVD looks similar to 'addcow'---use bitmap but delegating allocation to FS. However FVD seems to have been ignored by community.

Cheers!
       吴兴博  Wu, Xingbo <address@hidden>


On Tue, Aug 12, 2014 at 9:23 AM, Eric Blake <address@hidden> wrote:
On 08/11/2014 05:38 PM, 吴兴博 wrote:
> Hello,
>
>   The introduction in the wiki page present several advantages of qcow2
> [1]. But I'm a little confused. I really appreciate if any one can give me
> some help on this :).
>
>  (1) Currently the raw format doesn't support COW. In other words, a raw
> image cannot have a backing file. COW depends on the mapping table on which
> we it knows whether each block/cluster is present (has been modified) in
> the current image file. Modern file-systems like xfs/ext4/etc. provide
> extent/block allocation information to user-level. Like what 'filefrag'
> does with ioctl 'FIBMAP' and 'FIEMAP'. I guess the raw file driver (maybe
> block/raw-posix.c) may obtain correct 'present information about blocks.
> However this information may be limited to be aligned with file allocation
> unit size. Maybe it's just because a raw file has no space to store the
> "backing file name"? I don't think this could hinder the useful feature.

Search the list archives; at one point in the past, an 'addcow' format
was proposed, which is an additional file alongside a raw which provides
enough information to (temporarily) add cow to raw (or any other file
without a native backing file).  I don't know why that format was not
pursued further.

You could use xattr to store a user attribute of a backing file or
addcow file to associate with a raw file.  But file system holes are NOT
a good metadata tool for distinguishing between data not present (refer
to the backing file) vs. data explicitly all zero.  Your proposal of
using holes in raw files as metadata is NOT going to reliably work.

Also, using SEEK_HOLE/SEEK_DATA is a much nicer interface for iterating
raw file holes than FIEMAP.  It conveys less information, but that
information is more portable (POSIX will be adding requirements for
SEEK_HOLE/SEEK_DATA, and even NFSv4.2 is considering[1] adding this
support because of POSIX).  GNU cp is capable of using both FIEMAP and
SEEK_HOLE to optimize copies where the destination tries to preserve the
same hole layout as the source (not always possible, given that not all
systems have the same granularities of holes, and also given that not
all consecutive blocks of all-zero bytes have to be reported as holes).
 The SEEK_HOLE implementation has ALWAYS worked, but the FIEMAP
implementation uncovered various bugs in file systems, and at one point
would corrupt the copy unless cp did a sync() first, which slowed down
the operation and defeated the point of attempting to use it for
optimizations.  While holes are a cool thing, they are best only for
optimizations, and not for reliable metadata information.

[1]
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-26#section-15.12

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org



reply via email to

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