Hi, On Sun, Sep 1, 2019 at 1:52 PM Russell Senior <[email protected]> wrote: > >>>>> "Jonas" == Jonas Gorski <[email protected]> writes: > >> It contains a patch at the end titled: "[PATCH] base-files: pad > >> root.squashfs to 64KiB in ubi volumes" This is another approach that > >> just deals with the UBI+squashfs issue but works with > >> "-nopad". Soooooo.... do we all agree there? > > Jonas> a) 64k is excessive, we only need 4k (actually 1k would be > Jonas> enough, since we don't enable CONFIG_SQUASHFS_4K_DEVBLK_SIZE). > > Jonas> The referenced issue with 64k page size happens when > Jonas> loop-mounting a squashfs, since loop defaults to PAGE_SIZE as its > Jonas> block size. But we never do that in OpenWrt, and we don't support > Jonas> any targets with that huge PAGE_SIZE - biggest is ARC with 8k. > > Jonas> b) it misses the squashfs's in generic sysupgrade images itself - > Jonas> we need to pad their length as well, to avoid breaking devices > Jonas> with a sysupgrade image hitting the corner case being flashed > Jonas> from an unfixed firmware with the old nand.sh. > > Jonas> Also IMHO "1c0290c5cc6258c48b8ba46b4f9c85a21de4f875" should be > Jonas> reverted, for the previously mentioned issues. > > Afaict, only devices with LEB sizes of non-integer kilobytes (like the > MR24 with its 15.5k LEBs) need any intervention at all. Because > squashfs's are read in 1k blocks, there is a 1 in 62 chance of creating > a rootfs that is an inopportune size on 15.5k LEBs. I have a PogoPlug > v3 with LEBs of 126k, and a MikroTik RouterBOARD 493G with LEBs of > 124k. Neither of those is affected. > > I still kind of like my solution where we explicitly ask for padding for > devices that need it.
I see, fine. Tell you what, I'll let the two of you do what you want or not. My request to the both of you is, that instead of justreverting, please add a "why the -nopad has become essentially atechnical debt there". I'm not that familiar with these devices and their problems, so I don#t think I have anything more to add. Goodbye! _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
