22.4.2016, 0.48, Chuck Anderson kirjoitti: >> You could also try without --delay-updates, which also triggers this >> requirement to know the full file list in advance. > > But not using --delay-updates means that the yum repo could be in an > inconsistent/nonfuctional state until the sync finishes. That isn't > good for a public mirror. If also using --delete-delay, the files to be deleted will be deleted only at the end of sync, reducing the chances of anything breaking. Although I see your point, I believe the base repositories (os, updates, extras, fasttrack etc) would end up getting synced in such a sequence that yum won't get confused. The repodata directory tends to get synced last, and it is not harmful if there are .rpm files on the mirror that are not yet referenced in the repodata. For the directories that have a more exotic directory layout, such as "atomic", it might indeed be useful to have --delete-delay in use. However, for this particular case, testing one sync without that --delay-updates and --delete-delay instead of --delete-after might show if the problem is related to rsync needing to gather the full filelist. On the other hand, I might be entirely on the wrong track here.. rsync did transfer a few files before stopping, which doesn't quite fit well with my theory. Oh well. Perhaps it's a firewall problem then.