mail archive of the rauc mailing list
 help / color / mirror / Atom feed
* Re: [RAUC] Future update method tree-rsync-checksum
       [not found] <5496f060c3934cc9a523fe40975acb39@iemgroup.com>
@ 2023-04-12  9:57 ` Jan Lübbe
  0 siblings, 0 replies; only message in thread
From: Jan Lübbe @ 2023-04-12  9:57 UTC (permalink / raw)
  To: Alexandre Gambier, rauc

Hi Alexandre,

it seems we missed this mail, sorry.

On Fri, 2023-01-06 at 15:00 +0000, Alexandre Gambier wrote:
> I'm currently evaluating RAUC to replace our current casync implementation and
> after a look to your article
> :https://www.pengutronix.de/en/blog/2022-10-12-rauc-adaptive-updates.html, I
> was wondering if there's any public roadmap or if you can tell me when the
> future update method tree-rsync-checksum will be available.

Are you using casync directly or via RAUC?


Most of our feature improvements are developed in customer projects and driven
by a specific use-case. Currently, we don't have a project which requires the
tree-rsync-checksum method.

We've started a discussion with the rsync maintainer regarding a feature we'd
need in rsync [1], but it seems it will not be simple to get that into an rsync
release.

> Our product is battery powered and uses a Cat-M1 4G modem with a very
> expensive and limited data plain.
> So we need to download only the required files so we won't exceed the data
> plain and the machine can goes to sleep mode as fast as possible.

> The current update method block-hash-index downloads more packets than it is
> really necessary.

Yes. The block-hash-index is a different trade-off: It's very simple, usable for
verified boot setups and works with any old version on the target device. As a
down-side, it will need to download more data.


For your scenario, where you're likely paying for every packet, different
approaches would probably be more efficient.

Either something like the tree-rsync-checksum approach, which would still work
with any version on the target devices. It would still need to compare the hash
for every file, which still generates some traffic, and then download any
changed file completely.

To reduce the download size even more, you could use a delta approach: The
bundle would contain 'patches' to update from a set of old version you know are
in the field. During installation, RAUC would select and downlaod only the one
matching patch. This would also avoid downloading *parts* of files that are
unchanged. For file trees, we could use rsync batch files. For raw filesystem
images, zstd in --patch-from mode could be used.


To implement one of these approaches, we could take the commercial path (via
sales@pengutronix.de). Alternatively, we'd of course also take a PR adding
support for these from the community.


Best regards,
Jan Lübbe

[1] https://github.com/WayneD/rsync/discussions/423

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-04-12  9:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <5496f060c3934cc9a523fe40975acb39@iemgroup.com>
2023-04-12  9:57 ` [RAUC] Future update method tree-rsync-checksum Jan Lübbe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox