mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: "Jan Lübbe" <jlu@pengutronix.de>
To: Alexandre Gambier <A.Gambier@iemgroup.com>,
	"rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: Re: [RAUC] Future update method tree-rsync-checksum
Date: Wed, 12 Apr 2023 11:57:36 +0200	[thread overview]
Message-ID: <3dd18840cf2d9cbce2da69bf9e86623cb52687ff.camel@pengutronix.de> (raw)
In-Reply-To: <5496f060c3934cc9a523fe40975acb39@iemgroup.com>

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 |



           reply	other threads:[~2023-04-12  9:57 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <5496f060c3934cc9a523fe40975acb39@iemgroup.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3dd18840cf2d9cbce2da69bf9e86623cb52687ff.camel@pengutronix.de \
    --to=jlu@pengutronix.de \
    --cc=A.Gambier@iemgroup.com \
    --cc=rauc@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox