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
signature.asc
Description: OpenPGP digital signature