Re: How to deal with a large staticdelta that is a product of a bloated commit in our ostree repository

[Leon Woestenberg <leon sidebranch com>]

Hello all,

As a bad netiquette, responding to self, as the answer can be semi-found  in the updated documentation https://ostree.readthedocs.io/en/latest/manual/repository-management/

> We may also want to support client systems upgrading from two commits previous.
>
> ostree --repo=repo-prod static-delta generate --from=exampleos/x86_64/standard^^ --to=exampleos/x86_64>standard
>
>Generating a full permutation of deltas across all prior versions can get expensive, and there is some support in the OSTree core for static deltas which "recurse" to a parent.

>

What is "some" support in this case?

>

> This can help create a model where clients download a chain of deltas. Support for this is not fully implemented yet however.

>

Is this up-to-date with the current implementation? And what means "not fully"? Is it unreliable to use, or safe to try, as the client will fallback?

Regards,

Leon.

On Mon, Jan 29, 2018 at 10:07 PM, Leon Woestenberg <leon sidebranch com> wrote:

Hi Colin,

I like to understand this practical use-case better.

You can generate a delta from C to A and clients still on C will jump
right over B.

What is the command line equivalent to this action?

Regards,

Leon. 

On Wed, Jan 24, 2018 at 12:01 PM, Colin Walters <walters verbum org> wrote:

Hi,

On Tue, Jan 23, 2018, at 9:12 PM, Davis Roman wrote:
> Hi everyone,
>
> In my ostree repository I have a commit that creates a staticdelta of
> 380MB.  This was caused by a bug in our buildsystem as the staticdeltas in
> our system are normally significantly smaller than that (~7.5MB).

In this case some additional data (like debuginfo or whatever) got into the commit?

Did client systems already see the bad commit?  If not, then I think the simplest
solution is to reset the commit history.  It's just a matter of:

$ ostree --repo=repo reset examplecorp/42/x86_64/os 88453200a44c7a9919c458e1e0aaa058f1d9a520ad1ff0ae0a93d0efdf601267

(Or whatever you want the tip commit to be)

If (some) clients already *did* see the commit then remember due to the
way ostree deltas work (between arbitrary commit A to B), you can generate
a delta that skips the bad commit.  In other words given this history:

A: current tip
^
B: bad bloated commit
^
C: commit
^
D: commit
...

You can generate a delta from C to A and clients still on C will jump
right over B.

Does that help?
_______________________________________________
ostree-list mailing list
ostree-list gnome org
https://mail.gnome.org/mailman/listinfo/ostree-list