Jo-Philipp Wich <[email protected]> [2019-04-01 11:18:55]: > > Felix had a good point about sysupgrade, where we would needlesly write few > > dozen MBs of 0s. In order to avoid that, I would simply add following qemu > > variants to x86: > > I wonder what kind of storage media on x86 is so brittle that writing a > few dozen MB of 0s will cause any noticeable effect.
SD cards could be slow. So it's going to make a difference if you're going to write 20M or 273M combined image. On my apu2 with some noname SDHC SD card (~6MB/s write max) I get ~15s difference in writting squashfs image (unpadded=0.29s Vs padded=15s). I'm not sure if this is negligible or acceptable tradeoff, considering how minor is the QEMU use case. > Not opposed to that, but that nullifies the entire "save space on servers" > argument. It wasn't my argument. > Instead of having one set of images a few MB larger, we have a completely > new set of larger images *and* the existing ones. I'm all in for having usable images out of the box, without any additional post-processing steps, but on the other hand I understand, that this might slow down noticeably some existing use cases. BTW, we're talking on x86 probably about additional 40M (~10M per each of 4 subtargets) and 8 additional QEMU ready images. On armvirt/malta we're going to produce(if agreed upon) padded images by default, so no difference there. -- ynezz _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
