On Fri, Aug 3, 2012 at 6:56 AM, Dong Xu Wang <wdon...@linux.vnet.ibm.com> wrote: > 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.
Yes. Please update the spec because it says the opposite: "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" It should use the size of test.raw. Stefan