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 <wux...@gmail.com>
On Tue, Aug 12, 2014 at 9:23 AM, Eric Blake <ebl...@redhat.com> 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
>
>
