Talk:Mirrors

rsync errors in tier2 mirrors

It is possible for arch mirrors to be in an inconsistent state if rsync fails at some point. This is due to mirrors not generating their own package databases but rather copying the one from lower tier mirrors. In these cases, trying to grab a package from these mirrors may result in a 404 error due to incomplete syncing. The method described in Tier 2 requirements does not adequately protect this case.

The following code will re-run rsync if it ever fails to ensure mirrors are properly synced.

RET=1
COUNTER=100
until [[ RET -eq 0 && COUNTER -gt 0 ]]; do
 rsync -rtlH --safe-links --delete-after --progress -h --timeout=600 --contimeout=60 -p \
             --delay-updates --no-motd --bwlimit=4096 \
             --temp-dir="/tmp" \
             --exclude='*.links.tar.gz*' \
             --exclude='/other' \
             --exclude='/sources' \
             --exclude='/iso' \
       'rsync://mirror.pkgbuild.com/packages/' \
       "/srv/repo" &&
       RET=0
       COUNTER=$[COUNTER-1]
done;

—This unsigned comment is by Bluerider (talk) 21:55, 26 March 2015 (UTC). Please sign your posts with ~~~~!

List by speed procedure

Looking at the procedure for Mirrors#List_by_speed it seems a bit odd to me that it suggests editing the backup that was taken of the local mirror list. I would think the instructions should either suggest creating a second working copy to delete once completed or, since a backup has already been taken, just modify the mirrorlist in place rather than modifying the backup.

Thoughts?

Ocelotsloth (talk) 03:04, 24 April 2019 (UTC)

Sorting mirrors - Methods order

It seems to me that using reflector is easier and more powerful than using rankmirrors. What about putting it first for newcomers ?

Also, I was thinking about putting the part where you make a backup of mirrors at the beginning of this section.

Any objection ?

-- Apollo22 (talk) 11:26, 22 June 2019 (UTC)

Server-side ranking does not consider the user's location and the link speed between the user's computer and the servers, so rankmirrors is actually more powerful and the separate "server-side ranking" section makes sense. -- Lahwaacz (talk) 20:14, 22 June 2019 (UTC)

I agree but reflector has the ability to use both server side ranking and client side ranking. I planned to refactor it this way (none of the current content would be deleted):

 - (Section) Sorting mirros
   - Make a backup
 - Use reflector
 - Client side ranking
 - Server side ranking

-- Apollo22 (talk) 07:22, 23 June 2019 (UTC)

reflector regularly breaks where rankmirror does not (see the forum thread: [1]). The working/more reliable tool should be documented first, regardless of "user friendlyness". -- Alad (talk) 08:16, 23 June 2019 (UTC)

I fully agree with your point about stability vs freadlyness. However, I am less convinced by the **regularly breaks** point about reflector. So for now I'll keep rankmirror first, but I'll still try to make reflector more visible. -- Apollo22 (talk) 08:40, 23 June 2019 (UTC)

FTP mirrors

The article remarks "HTTP mirrors are faster than FTP due to persistent HTTP connection: with FTP, a new connection to server has to be established each time pacman requests a package to be downloaded, which results in a brief pause." However there aren't any FTP mirrors on the mirror list. Is this note obsolete and can be removed? --Pyfisch (talk) 17:52, 20 February 2021 (UTC)

An argument against removing the note: there can still be FTP mirrors in internal networks. Just because there are not any public mirrors using FTP anymore does not mean that there are no mirrors using FTP.

-- NetSysFire (talk) 17:56, 20 February 2021 (UTC)

There are still some unofficial mirrors serving over FTP. -- Lahwaacz (talk) 08:27, 21 February 2021 (UTC)

Actually, that remark might not be accurate anymore, since pacman v6 uses curl multi handle (which allows multiple connections etc.). Ideally it should be re-tested with some FTP server whether a connection is re-used or a new connection is re-estabilished as it says. Quick searching suggests libcurl should re-use FTP connections just like HTTP, so this seems a bit odd. P0358 (talk) 22:02, 17 March 2025 (UTC)

No mention of the order of repos

What is missing to me, is some very clear and explicit description about mirror picking order. I had to delve into pacman's code to determine that (for better or worse) downloads always attempt mirrors from first to last on a per-file basis, falling back to the next one if the current one failed (be it due to connection error/timeout/domain resolve failure/4xx error including 404).

And what ParallelDownloads option does, is it attempts to download multiple files at once, each separately executing the above logic. It does not, as one might wrongly assume, multiplex multiple mirrors at once. If the first mirror listed is working, then only that one will be used for downloads and the other ones won't be attempted at all. If it has some crazy low download throughput bottleneck, then tough luck.

I think laying that knowledge out is crucial for the user to properly understand how they should approach populating their mirror list, and how important the ordering will be. I'd have edited the article, but I have no idea how to word it... Some of what I mentioned here could be incorporated into Pacman's page too perhaps.

And I am not making a critique of Pacman here: the logic it uses can be useful to do something like adding Arch archive repo as the last fallback in case all other mirrors result in 404 for the package. P0358 (talk) 22:08, 17 March 2025 (UTC)

I've added [2] to clarify your first point a little.

Regarding ParallelDownloads, we cover it in Pacman#Enabling parallel downloads, but implicitly the same applies. Yes, you can run into bottlenecks (e.g. kernel.org may be notorious for it due to popularity), but there are many variables that primarily depend on the user's uplink. The whole Mirrors#Sorting mirrors section deals with options. I think this is covered. The Arch archive is more a last resort when you require a specific package release (e.g. failing rolling kernel modules). It's not a good idea to list it among the regular mirrors in my opinion.

Thanks for the input. closing, re-open if you disagree. --Indigo (talk) 20:27, 18 March 2025 (UTC)