On Wed, Nov 24, 2021 at 8:10 AM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > On Tue, 23 Nov 2021, David Anderson wrote: > > > In our ecosystem, the OTA generation and on-device application process > > has evolved continually, in every release, for over 10 years now. So > > we think it's unlikely that we'll stop making improvements to it. Our > > current roadmap has other changes in the pipeline too. It's not just > > us trying to eek out diminishing returns. Other parts of the system > > change around us, and the OTA system needs to adapt. > > > > The performance penalty is something we've been working on, and have > > improved a lot since our first iteration. We're currently > > experimenting with io_uring as well. > > > > Best, > > > > -David > > Hi > > I understand that an update format developed over 10 years will have > better compression ratio than my format developed in 2 months. > > I'd be interested in extending dm-update to handle your your update format > and possibly add some abstraction, so that it can work with multiple > formats. > > You say that you have "COPY" and "XOR" operations. > > How do you search for blocks that are similar, so that the "XOR" method is > benefical for them? How do you make sure that you don't perform the "XOR" > operation twice, if there's system crash when performing it? CC: Kelvin and Tianjie who are familiar with the OTA generation. > Could it be possible for you to give us two Android images and a program > that calculates difference between them? So that we could see how well we > are performing compared to the existing solution. > > Mikulas > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel