Yum, metadata, and download avoidance/control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

I've worked on an idea the last while which could possibly help with the extremely large (if you look at what 
the contents vs size ratio is, as well as how often downloads are justified because of repo content changes). 
Example situation:

Repo contents change a few times per day. Now let's say that the indexing of the repo is done quite a few 
times, but in a sane fashion..so let's fix that at 8 times per day. That's once every 3 hours. Sounds 
reasonable enough (to me, anyway..I'm open to correction or so if I'm wrong or if there is a standard timing 
I don't know about or such). This would often lead to regular, overly occurring metadata downloads (this is 
something I hear a lot of people regularly complaining about in IRC channels which use the yum/rpm system for 
package management), and also in many cases to repos being out of sync and thus an even larger amount of time 
which is spent on repo metadata downloads due to the 'Does not match checksum' error.

What I propose is as follows:

Suppose you have a repo:
{start}-------------------------------------------------{end}

Normally would be downloading an index of that entire repo even if just one little file changed. Now, what if 
you could have yum check which section of the repo changed, and then only download the changed repodata index 
file?

{start}---------------------{split}-------------------------{end}

In the 2nd example, you use md5 or sha1 to generate a hash of the index files, and then have the client side 
compare. If it does not match what the server is reporting, then download the index file for that segment 
only. This could of course be subdivided/implemented a slight bit below only one execution level too. 
Obviously there would be a limit at where the download of hashes versus the index count would be neglible, 
but overall the download times/size would/should come down.

Any comments and questions welcome and appreciated.

Regards
JP
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxxxxx
https://lists.dulug.duke.edu/mailman/listinfo/yum

[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux