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?
Anyways, adding the missing 64k modulo bytes works, I just tested it. Thanks both of you for the analysis and help!
Ilkka Tengvall PS, evidence of the success :) : starting filesystem compression minimizing root partition on [/dev/loop2p1] - file check /dev/loop2p1: 56193/102544 files (0.1% non-contiguous), 222914/409600 blocks minimizing root partition on [/dev/loop2p1] - resizing minimizing root partition done [/dev/loop2p1] - again file check /dev/loop2p1: 56193/63104 files (0.4% non-contiguous), 220426/230381 blocks the new size is [230381] of [4096] sized blocks, copying it out to [root.fs] we need to add [12288] extra bytes to image to make the compression work 943652864+0 records in 943652864+0 records out 943652864 bytes (944 MB) copied, 2304,77 s, 409 kB/s packing the filesystem Completed. See 'ls -lah vmlinuz* initrd* root.fs done building
