Dne 21. 12. 20 v 17:39 Neal Gompa napsal(a):
On Mon, Dec 21, 2020 at 11:29 AM Ben Cotton
<bcotton(a)redhat.com> wrote:
> # Decompression happens inline with download. This has a positive
> effect on resource usage: downloads are typically limited by
> bandwidth. Decompression and writing the full data into a single file
> per rpm is essentially free. Additionally: if there is more than one
> download at a time, a multi-CPU system can be better utilized. All
> compression types supported in RPM work because this uses the rpm I/O
> functions.
> # RPMs are cached on local storage between downloading and
> installation time as normal. This allows DNF to defer actual RPM
> installation to when all the RPM are available. This is unchanged.
> # The file format for RPMs is different with Copy on Write. The
> headers are identical, but the payload is different. There is also a
> footer.
> ## Files are converted (“transcoded”) locally during download
using
> <code>/usr/bin/rpm2extents</code> (part of rpm codebase). The format
I cannot find it anywhere in rpm codebase.
> # Disk space requirements are expected to be marginally higher
than
> before: all new packages or updates will consume their installed size
> before installation instead of about half their size (regular rpms
> with payloads still cost space).
The size is alreay an issue (for me) on small cloud images. But I do not use BTRFS there.
So at the end I do not care :)
>
> Ballpark performance difference is about half the duration for file
> download+install time. A lot of rpms are very small, so it’s difficult
> to see/measure. Larger RPMs give much clearer signal.
Hmm, I, personally, see much better perfomance (and storage) improvements in enabling
%_minimize_writes
however there is still
https://bugzilla.redhat.com/show_bug.cgi?id=1872141
to be resolved before this got enabled by default.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys