It seems garuda-update refreshes mirrorlists far too often

[magnus-ISU]

I update a lot. It's compulsive behavior I guess

Anyway, running garuda-update by default refreshes mirrors every time you run it, even though reasonably you don't need to do that more than once a week or month or so.

I call a wrapper around garuda-update which will do the following now:

# Update the system, if it has been longer than a day since it was updated (or a reboot - don't clutter the filesystem)
export SKIP_MIRRORLIST=1
datefile=/tmp/garuda-update-mirrorlist-refreshed
ten_days=864000
[[ -f $datefile ]] && [[ $(( `date +%s --utc` - `cat $datefile` )) -le $ten_days ]] || {
        unset SKIP_MIRRORLIST
        date +%s --utc > $datefile
}

Basically, set SKIP_MIRRORLIST to 1 if the mirrors have been updated in the past 10 days.

I think garuda-update should probably do something similar to this by default; though probably with a somewhat smarter method to deciding not to update.

[filo]

Garuda Update

You can call it as parameter, as I normally do, or configure it.

[meanruse]

As far as I understand, indeed once a good set of mirrors have been found, there's no need to refresh the mirrorlist unless some start failing or become too slow.

I read that it's actually better not to, to avoid potential problems with mirrors being "misaligned" (so to speak) if they don't update at the same time.

I also normally --skip-mirrorlist.

I think the reason for the default mirrorlist refresh is to work around PEBKAC issues with bad mirrorlists preventing system upgrades.

[Locutus]

Agree no need to update mirrors every time one does updates.

[BluishHumility]

@meanruse

I think the reason for the default mirrorlist refresh is to work around PEBKAC issues

Layer 8 issues.

Petsam wrote an article a couple months back about the significance of updating the mirrorlist, and how it is a process that is often mishandled and misunderstood. It’s worth a read if anyone wants to learn a bit more about the topic or be exposed to a different point of view. The article is posted on the wiki section of the GitLab page for his SafeSync application.

Exhausting explanation about mirrorlist handling · Wiki · Πέτρος / SafeSync ·...

After reading the article, I decided to give running a single mirror a try and made an effort to figure out what the “best” mirror for me would be. Every day I would run Rate Mirrors and note the top ten HTTPS mirrors in a spreadsheet, thinking that I could after a few weeks identify a mirror that was consistently in the top ten and just set that as my permanent mirror.

I quickly ran into a problem with very inconsistent results. The top ten mirrors from one day might not even be in the top thirty the next day. I realized pretty much anything could be causing this–local or non-local bandwidth conditions, or something happening with the mirror itself…even the fact that people are rating mirrors and updating off the fastest one. If 100 people identify the fastest mirror and update off of it at the same time…well, it’s not going to be the fastest mirror anymore.

Since my spreadsheet was turning into a very random-seeming list of mirrors with hardly any repeat entries, I decided to scrap the whole idea of finding the “best” mirror, and just find something reliable and good.

I discovered MIT maintains Arch mirrors; it’s a school with a good reputation that happens to be geographically close to me, so I figured I would give it a shot. So far () it has been great! Fast updates, no mirror issues, and no waiting around for Rate Mirrors to finish.