Skip to content
@RubenKelevra edited this page May 28, 2020 · 8 revisions

Why can't I access the ipfs mirror?

You're running an IPFS-version prior to 0.5.0.

The IPFS-versions 0.4.x and 0.5.x have some breaking capabilities. Make sure to use the latest version of IPFS to be able to access the mirror.

Why does the Pacman downloads times out?

Your IPFS-Client stalled

There's a known bug in the IPFS-Client which leaves your client in a very bad connection state to the network. This bug is reported and is currently worked on by the developers.

It's often triggered when the network setup changes or there are small outages in the Wifi connection.

ipfs/go-ipfs#7211

You haven't turned on pubsub and namesys-pubsub

The currently recommended flags for the IPFS daemon are --enable-gc --enable-pubsub-experiment --enable-namesys-pubsub.

  • enable-gc turns on the garbage collection. This functionality will remove all cached items when you're exceeding the configured cache size.
  • enable-pubsub-experiment and enable-namesys-pubsub turn on fast name-lookups, which are required for low latency download starts.

Pacman has too low timeouts

Pacman waits 10 seconds for a startup of a download and will jump to the next server.

Especially on the first download(s), like the database files, IPFS has some trouble to fulfill the request in 10 seconds currently (2020-05-21). You can remove the Pacman timeouts with --disable-download-timeout on the Pacman call. The different solution is to add the same IPFS-Server URL multiple times to your mirror list, to give IPFS a second chance to fulfill the request (which should work fine).

The cluster might have a known issue

Take a look at the Status-Page. If no issue is known, feel free file a bugreport

Following the cluster: Why does the initial sync with the cluster take so long?

This is a limitation by ipfs-cluster

Currently, every update on the mirror is two commits to the cluster-pinset (one remove and one add). Since the full history of elements has to be traversed, this will take a while, until your cluster-follower has caught up.

The processing only runs through the metadata of the cluster, so only the latest version of the data in the cluster has to be downloaded, not each and every package which was once part of the cluster.

This limitation will soon be removed, reducing the commits (probably) one commit for each update of the mirror, regardless how many packages have been modified at once.

See: ipfs/ipfs-cluster#1008 and ipfs/ipfs-cluster#1018

My IPFS-client uses too much memory

You have enabled QUIC (version 0.5.x)

QUIC is currently not fully stable (thus being marked as experimental). It's recommended to disable QUIC for now (status: 0.5.1).

See ipfs/go-ipfs#7211

My IPFS-client uses too much storage

Enable GC

It's recommended to enable the garbage collector, to avoid filling more storage than configured. Else you would have to run the garbage collector manually with ipfs repo gc.

Reduce the configured maximum disk space

IPFS uses by default a maximum of ~9GB disk space. To reduce this, you can change the configuration with for example:

ipfs config --json Datastore.StorageMax '"8GB"'

This config change requires a restart of the IPFS-daemon.

You're using the badger datastore

The badger datastore uses a fast database instead of the normal flat-fs configuration. Currently, IPFS doesn't fully clean up old elements, so the datastore might grow without a limit (since the garbage collector cannot regain any disk space).

This issue has been reported and is currently looked into by the IPFS-developers:

ipfs/go-ds-badger#54