[LEDE-DEV] [RFC] filesystem-agnostic sysupgrade backup system

[Felix Fietkau]

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