Currently, when builderv2 retrieves root.img from a DispVM, it doesn't preserve file sparseness. It then needs to call fallocate -d to restore its sparseness. This means one need a lot more space (at least temporarily) to successfully build a template, but also it's slower.
The solution you'd like
Add an option to qfile-unpacker to detect ranges of zeroes (either with hardcoded granularity, or maybe with fs block size granularity) and seek over them instead of writing those zeroes to the file. The wire format should remain unchanged (which means still sending a lot of zeroes, but this part is fast).
The value to a user, and who that user might be
Less disk required to build templates, less ssd wearing.
Completion criteria checklist
(This section is for developer use only. Please do not modify it.)
[ ] implement as described above
[ ] ensure files with leading/trailing zeroes are still handled correctly (for example ensure they aren't end up being shorter)
[ ] add unit tests (something like socat EXEC:"qfile-agent ..." EXEC:"qfile-unpacker ..." should work)
How to file a helpful issue
The problem you're addressing (if any)
Currently, when builderv2 retrieves root.img from a DispVM, it doesn't preserve file sparseness. It then needs to call
fallocate -dto restore its sparseness. This means one need a lot more space (at least temporarily) to successfully build a template, but also it's slower.The solution you'd like
Add an option to qfile-unpacker to detect ranges of zeroes (either with hardcoded granularity, or maybe with fs block size granularity) and seek over them instead of writing those zeroes to the file. The wire format should remain unchanged (which means still sending a lot of zeroes, but this part is fast).
The value to a user, and who that user might be
Less disk required to build templates, less ssd wearing.
Completion criteria checklist
(This section is for developer use only. Please do not modify it.)
socat EXEC:"qfile-agent ..." EXEC:"qfile-unpacker ..."should work)