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

Re: Fedora extras metadata

Michael Schwendt wrote:

What does the algorithm look like?

"Handshake" implies bidirectional communication, which is not
available. We only have "slave retrieves from master" or "slave retrieves
from slave" relationships. Mutual exclusion is not possible either. Flag
files don't make the mirroring an atomic operation. The master can still
break the scheme and push updates while a mirror is downloading in believe
that the previously checked flag file was up-to-date.

IIRC, something like echoing the output of `date` into af file named "mirror.wherever.com" in a special dir, upon successful synchronization from upstream mirror. That same file would be deleted when starting the next sync (there are tricks you can do, like download new packages to a temporary dir before deleting old packages and moving stuff in place, to shorten that period as much as possible). The point would be that if I'm syncing from mirror.somehost.com, I can check if the file mirror.somehost.com exists before even trying. If it exists, the mirror is consistent, but could still be stale. Staleness would be evident from the timestamp.

Also, since we would sync the special directory with the mirror.somehost.com file, we can even track problems to watever upstream mirror host and check how old this particular set of packages has been on their way from the main site.

Something along those lines.

See http://www.debian.org/mirror/ftpmirror for more info on how the debian project does it, and perhaps we can be inspired by that. search for project/trace on that site, since that's where they'll throw the timestamp file.


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