On 2017-11-16 14:05, Thibaut VARÈNE wrote: > Hi, > > Following up on [1], I propose a different way of handling sysupgrade backups > that would no longer rely on a filesystem stub (jffs2, ubifs or otherwise). > > Note: the following elements describe squashfs with jffs2 overlay images, but > I suspect they apply to more cases (ubifs…). > > Current status: > - When sysupgrade is asked to preserve the device configuration over reflash, > the process will: > - prepare a tarball of the config data onto tmpfs > - embed it into a filesystem stub appended after the squashfs data > - append a specific marker (deadc0de) to designate the end of the valid > jffs2 segment > - When the new image boots: > - the squashfs mtdsplitter locates the end of the squashfs image and > places the beginning of the rootfs_data partition after it > - the jffs2 stub is now located at the beginning of the rootfs_data > partition (the writeable overlay) > - a LEDE-specific patch to the jffs2 driver clears the nodes located > after the marker > - the overlay is then mounted and the data it contains is recovered. > > This has several drawbacks, as [1] illustrates: in particular it makes it > complicated, if not impossible, to change the filesystem used on the overlay > or any of its parameters - such as sector size in the case of jffs2 - without > losing the backup data. I'll take another look at your proposal for the new format soon when I have time, but I would like to comment on the issue of switching between images with different sector sizes. I think this is entirely fixable without switching to a different format, and would mostly require solving things you need to solve for your suggested format change as well. The mtd jffs2write functionality looks for the right place to store its data by finding the deadc0de marker. Thus if you want to make images agnostic of sector size changes, you could pad them with 0xff to 64 KiB size first, and then append the deadc0de marker afterwards. When switching from 64K sectors to 4K sectors, jffs2 will treat the padding as empty sectors and re-format them and will parse the stored config data afterwards. When switching from 4K to 64K sectors, the padding will simply be skipped over and everything should work just fine. I think it should be possible to solve this entirely within the image building code, with no further changes to user space or kernel space code. Thoughts?
To get started on making it possible to change the format, I would suggest getting rid of pure-jffs2 images in all targets first. - Felix _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
