Hi Michael, > On 17 May 2023, at 20:19, Michael Richardson <m...@sandelman.ca> wrote: > >> Lukas Zeller <l...@plan44.ch> wrote: >> [...] >> - trying to just zero out enough blocks after the squashfs data in >> `target/linux/bcm27xx/base-files/lib/upgrade/platform.sh` >> [...]
> I'm not really clued in to the subtlies here, but it seems like a TRIM is > missing that would have told the SDcard that there was just no data after the > new image. Yes, that's the objective - making sure what follows the squashfs data can't be falsely taken as a f2fs. > That should result in zeros being returned rather than garbage. I'm not sure it would actually ensure returning zeroes. AFAIK TRIM is only a hint to the SSD controller that it MAY erase the trimmed blocks, but it's the controller's decision if and when to do that. In practice, that likely depends on the access pattern, SSD controllers will start erasing blocks when there's nothing else to do or space is urgently needed. Hard to say if a given SDCard would actually erase between writing the image and the next boot. As these steps happen in immediate succession, I would rather guess the controller gets not enough spare time. Anyway, the problem is more complicated because the bcm27xx sysupgrade should be able to handle multiple partitions possibly following the one that is reserved for combined squashfs/f2fs. What is currently above my head is reliably figuring out which blocks to zero out (be it by TRIM or just dd-ing zeroes). Plus, I'm not sure yet that just zeroing space is the correct fix at all. The entire sysupgrade is obviously cleanly architected and implemented - but the almost complete lack of comments makes it hard to understand it to the point to be able to suggest a change. I guess I'll need to dig trough all of it until I understand every single line before I dare to patch something. Because that's quite a way to go, I am hoping somebody with more insight could help a bit ;-) Lukas
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
