On Fri, Nov 7, 2014 at 3:31 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
the meta-data are fat
look below
The metadata are bulky, fairly monolithic databases. They cannot
easily support incremental updates of the metadata because they are
compressed, singular files storing data for all available packages.
The bandwidth and storage costs are thus singificant.
It's nowhere near as bad as I'd concluded from my back-of-the-envelope
calculations because the base OS metadata is stable, the churn is
among the updates, and the expiration is set longer than I'd realized
on Fedora. (I'd been looking at the defaults and making unwarranted
conclusions about update frequency from RHEL experience.)
[root@rawhide ~]# rm -rf /var/cache/dnf/*
[root@rawhide ~]# df
Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb1 ext4 12G 598M 11G 6% /
/dev/sda1 ext4 487M 35M 448M 8% /boot
[root@rawhide ~]# dnf --disablerepo=koji info kernel 2> /dev/null >
/dev/null
[root@rawhide ~]# df
Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb1 ext4 12G 713M 11G 7% /
/dev/sda1 ext4 487M 35M 448M 8% /boot
[root@rawhide ~]# rm -rf /var/cache/dnf/*
I do think you also flushed all the historical data on what packages
were installed from what repositories, and local cookies, when you did
that. Next time, just use 'dnf clean metadata*' and 'dnf list, to
avoid playing with anything else. The "du" command will also gove you
a lot more detail about what is taking up all the space.
Overall. Yest, it's bulky. 'deltarpms' does not help with this
underlying churn required for even reporting new available packages. I
still think that, for most folks, it's a larger bandwidth burden than
the occassional update, but that's no longer the case if you update
packages frequently.