Michael Schwendt wrote:
/Thomas
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.
/Thomas
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
