On Fri, Nov 7, 2014 at 3:31 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
