On Wed, Oct 12, 2016 at 06:04:09PM -0700, Seth Arnold wrote: > On Wed, Oct 12, 2016 at 02:20:31PM -0700, Steve Langasek wrote: > > Are you proposing to do away with this auto-expansion capability? If so, > > this implies that:
> How often does this auto-expansion fail? I have not heard of it failing. This is a straightforward operation involving resize2fs and a partition table change from the initramfs before the system has booted. This is the existing behavior within the core snap, and has been exercised for some time. > How much memory does it take? How much time does it take? (And do either > of these scale with the destination size?) I haven't measured either of these, but Oliver hasn't complained (aside from the one recent bug where ubuntu-image would sometimes create the initial ext4 filesystem with wrong options, leading to wrong resize times). I'm sure he would have let us know if this was causing noticeable delays on first boot. ;) These should always scale very well with respect to filesystem size, just as ext4 itself does, as in every case we're only moving around a small bit of filesystem structure. > What happens if the image is written to e.g. an SD card that previously > had data on the rest of it? Is there a risk that the old "garbage" is > available to applications? Only if there is a bug in the kernel's ext4 driver that allows reads of uninitialized data. -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- Devices mailing list Devices@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.snapcraft.io/mailman/listinfo/devices