<div dir="auto">1. OTA does not control placement of files. That’s done by file systems(ext4)</div><div dir="auto">2. OTA work at block device level. Not file level</div><div dir="auto">3. Often times, a file would have few of its blocks changed/shuffled, and rest of the blocks retain old content.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 29, 2021 at 06:05 Mikulas Patocka <<a href="mailto:mpatocka@redhat.com">mpatocka@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
On Tue, 23 Nov 2021, Akilesh Kailash wrote:<br>
<br>
> With OTA, it is challenging to have one general COW format - for instance<br>
> what is good for the Android ecosystem may not be useful for the<br>
> enterprise world.<br>
> For ex: Most of the space savings in Android comes from COPY operation i.e<br>
> for an incremental OTA, we would have metadata which states:<br>
> <br>
> COPY BLOCK X -> BLOCK Y<br>
> <br>
> There is no compression involved with these operations. Compression is only<br>
> when a block is "replaced". All these are too specific to the Android ecosystem.<br>
<br>
Why does Android OTA need the COPY operation? If a file is not changed by <br>
the update, the file could be placed at the same location and no update of <br>
the file is needed. If a file is changed, it is improbable that the new <br>
file will contain permutation of blocks of the old file, so I don't see <br>
how COPY will help here.<br>
<br>
Mikulas<br>
<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sincerely,<div><br></div><div>Kelvin Zhang</div></div></div>