After investigating why every release seems to take hours, we noticed
that even in zero-delta updates where nothing has changed upstream,
we'd get a utimensat() call that updated the modified time nanoseconds
portion; e.g.
lstat("Everything/x86_64/Packages/a/arch-install-scripts-23-1.fc31.noarch.rpm", {st_mode=S_IFREG|0644, st_size=28004, ...}) = 0
utimensat(AT_FDCWD, "Everything/x86_64/Packages/a/arch-install-scripts-23-1.fc31.noarch.rpm",
[UTIME_NOW, {tv_sec=1585676005, tv_nsec=6041000} /* 2020-03-31T17:33:25.006041000+0000 */], AT_SYMLINK_NOFOLLOW) = 0
This does not apply; in fact openafs uses the ns field as some sort of
generation counter [1]. This update is enough to convince openafs the
file has changed and it needs to be resynced, meaning that basically
every rsync run results in a full release.
This unnecessary update been fixed with [2] but is only in rsync
3.1.3+; our bionic host is currently 3.1.2. Dropping "-t" from the
rsync commands avoids transferring modification times and should avoid
this problem.
While looking, "-D" turns on "--devices" and "--specials" to transfer
block devices and named sockets/fifos. Turn this off.
Also remove "-p" if it was present. We already did this for centos
with Ib5db052cdd23e39aecbeead15cf08d4bd7fcab38 and Fedora with
Id24196791f80cd99fe8a330fb2c7c6d893fc9995, where odd upstream
permissions such as setgid on directories can't be synced to afs.
Consistently remove it.
Also switch back the fedora updates to just "-v"; we had it at "-i"
for debugging.
[1] http://eavesdrop.openstack.org/irclogs/%23opendev/%23opendev.2020-06-15.log.html#t2020-06-15T02:58:08-2
[2] https://git.samba.org/?p=rsync.git;a=patch;h=0f8e9e2d8638e47d646a6baba694b303ac84e695
Change-Id: I78f3d4990b168c71185eb1c4900ceeaca4b6a16f
4918594aa4