On Mon, Apr 15, 2013 at 1:00 PM, Ilkka Tengvall <ilkka.tengv...@cybercom.com> wrote: > On 15.04.2013 09:52, Stefan Hajnoczi wrote: >> >> I discussed the bug with kwolf on Friday. Although I sent a patch to >> add an error message when the input image length is not a multiple of >> cluster_size, Kevin pointed out that we can allow the final cluster to >> be zero-padded beyond the end of the virtual disk. >> Stefan > > > I second that. As an end user it is just extra complication to do that > manually. Especially if the device really ends at the non 64K boundary, it's > extra trouble to extend the device first. Not to talk about complicating the > auto build scripts by needing to add the size calculations before all > compressions. > > In my case I don't mind if there is some extra bytes of zero at the end of a > file size of hundreds of megs. I do understand the purity aspect though, not > getting the exact same copy while doing the conversion back. Could there be > a compatibility switch, that would handle the error automatically if one > doesn't care about converting back to original image?
A compatibility option won't be necessary because the virtual disk size will not be extended. This means that the image can be converted to raw without a change in disk size. The trick is that although we will compress a padded cluster, the virtual disk size will remain unchanged. The zero bytes will not be accessible, they will just automatically pad to the required alignment. Stefan
