linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Claudius Heine <ch@denx.de>
To: Andrei Borzenkov <arvidjaar@gmail.com>, linux-btrfs@vger.kernel.org
Cc: Henning Schild <henning.schild@siemens.com>
Subject: Re: btrfs-send format that contains binary diffs
Date: Mon, 29 Mar 2021 21:14:04 +0200	[thread overview]
Message-ID: <5ba46b04-f3ba-03ef-6ad5-38fd44f8c67e@denx.de> (raw)
In-Reply-To: <db6fae67-6348-1de3-c953-a4c75c459b65@gmail.com>

Hi Andrei,

On 2021-03-29 18:30, Andrei Borzenkov wrote:
> On 29.03.2021 16:16, Claudius Heine wrote:
>> Hi,
>>
>> I am currently investigating the possibility to use `btrfs-stream` files
>> (generated by `btrfs send`) for deploying a image based update to
>> systems (probably embedded ones).
>>
>> One of the issues I encountered here is that btrfs-send does not use any
>> diff algorithm on files that have changed from one snapshot to the next.
>>
> 
> btrfs send works on block level. It sends blocks that differ between two
> snapshots.

Are you sure?

I did a test with a 32MiB random file. I created one snapshot, then 
changed (not deleted or added) one byte in that file and then created a 
snapshot again. `btrfs send` created a >32MiB `btrfs-stream` file. If it 
would be only block based, then I would have expected that it would just 
contain the changed block, not the whole file. And if I use a smaller 
file on the same file system, then the `btrfs-stream` is smaller as well.

I looked into those `btrfs-stream` files using [1] and also [2] as well 
as the code. While I haven't understood everything there yet, it 
currently looks to me like it is file based.

> 
>> One way to implement this would be to add some sort of 'patch' command
>> to the `btrfs-stream` format.
>>
> 
> This would require reading complete content of both snapshots instead if
> just computing block diff using metadata. Unless I misunderstand what
> you mean.
I think I should only need access to the old snapshot as well as the 
`btrfs-stream` file. But I currently don't have a complete PoC of this 
ready.

regards,
Claudius

[1] https://github.com/sysnux/btrfs-snapshots-diff
[2] https://btrfs.wiki.kernel.org/index.php/Design_notes_on_Send/Receive

  parent reply	other threads:[~2021-03-29 19:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29 13:16 btrfs-send format that contains binary diffs Claudius Heine
2021-03-29 16:30 ` Andrei Borzenkov
2021-03-29 17:25   ` Henning Schild
2021-03-29 18:00     ` Martin Raiber
2021-03-29 19:25       ` Claudius Heine
2021-03-29 19:14   ` Claudius Heine [this message]
2021-03-29 19:53     ` Lionel Bouton
2021-03-30  7:48       ` Claudius Heine
2021-03-30  5:33     ` Andrei Borzenkov
2021-03-30  5:38       ` Andrei Borzenkov
2021-03-30  8:12         ` Claudius Heine
2021-03-30 16:32           ` Henning Schild
2021-03-31  1:17           ` Zygo Blaxell

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=5ba46b04-f3ba-03ef-6ad5-38fd44f8c67e@denx.de \
    --to=ch@denx.de \
    --cc=arvidjaar@gmail.com \
    --cc=henning.schild@siemens.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).