On Thu, Aug 2, 2012 at 6:44 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Thu, Aug 2, 2012 at 8:09 AM, Dong Xu Wang <wdon...@linux.vnet.ibm.com> > wrote: >> On Wed, Aug 1, 2012 at 9:55 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >>> On Tue, Jul 31, 2012 at 5:51 PM, Dong Xu Wang >>> <wdon...@linux.vnet.ibm.com> wrote: >>>> +test.raw may be larger than ubuntu.img, in that case, the size of >>>> test.add-cow >>>> +will be calculated by the size of ubuntu.img, test.raw will be used from >>>> the >>>> +1st byte, the rest part can be used for other purpose. >>> >>> This is not how backing files normally work. With qcow2 or qed a >>> smaller backing file just means that the guest reads zeroes from the >>> areas beyond the end of the backing file. Is there a special reason >>> why you want to implement the behavior you described in the spec? >>> Otherwise I suggest implementing the same behavior as qcow2/qed. >> >> The size of add-cow will be caclulated by the size of backing_file, if >> backing_file can be smaller, how can I get the size of add-cow while >> being created? >> >> Do you mean like following steps? >> 1) qemu-img create -f qcow2 source.qcow2 *8G* >> 2) qemu-img create -f t.add-cow -o backing_file=source.qcow2,image_file=t >> *10G* >> And then reading un-allocated bytes from add-cow after 8G will be 0? > > Yes. You could also get the virtual disk size from the size of the > image_file during creation.
Eric said I shoud make sure we also support a raw file larger than the backing file. so add-cow will have the same virtual size with image_file, and their virtual size can be larger than backing_file's. Am I right? Thanks. > Stefan >
