Hi Gustavo, On Wed, Oct 12, 2016 at 04:04:22PM -0300, Gustavo Niemeyer wrote: > We've discussed multiple times in meetings and threads that we want to > represent the content of the images accurately inside gadget.yaml. The fact > we're not yet doing that is a bug that we need to fix, and if there's > disagreement we should talk about it.
The disagreement is about whether this padding is a fundamental property of an image. Currently, all of the images that we create are minimally sized to be only as large as necessary to accommodate their contents, and they are expanded on first boot to fill the media that they've been written to. This is an important optimization in the image creation pipeline (both for developer use cases and - I believe - in the factory scenario), because it saves us having to write a lot of zeroes over a slow I/O channel for the empty space in a filesystem. Are you proposing to do away with this auto-expansion capability? If so, this implies that: - each media size will need to be treated as a separate "image", and either the gadget or the model (depending on outcome of this discussion) needs to be changed to make an image for 2G vs. 4G vs. 8G [...] SD cards - writing the image to the media will take longer (~4x longer for a 2G image, even more for larger images), slowing down the factory process, and impose more wear on the media This does not sound like a good outcome to me. And if we don't want this outcome, then conversely, the overall image size is not a property of the gadget or the model. And if it's not a property of gadget or model for the write-to-SD-card or master-device-in-factory cases, then I don't think we should shoehorn it into the gadget or model for the VM image case. Putting it another way. If we implemented this 'ubuntu-image --image-size=4G' option, it would be exactly equivalent to someone running 'dd if=/dev/zero of=my-vm.img bs=1G seek=4 count=0' as a post-process step - i.e. an fseek() and ftruncate() to extend the image, with no other changes. If I did that to a VM image locally, would you consider that a different "image"? Do you want something to consider this image an invalid instance of the gadget or model? (If so, why?) > The whole point of redesigning these tools is to evolve the status quo > towards something we are aiming at with underlying goals. If we are going > to rush it in, we can just pick up the tooling we had (or the hack you > mention) and put the images out. What is lacking at the moment is agreement about the underlying goal in this case, rather than agreement about how to get there. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: PGP signature
-- Devices mailing list [email protected] Modify settings or unsubscribe at: https://lists.snapcraft.io/mailman/listinfo/devices
