- Why can't I access the ipfs mirror?
- You're running an IPFS-version prior to 0.5.0.
- Why does the Pacman downloads times out?
- Your IPFS-Client stalled
- You haven't turned on pubsub and namesys-pubsub
- Pacman has too low timeouts
- The cluster might have a known issue
- Following the cluster: Why does the initial sync with the cluster take so long?
- This is a limitation by ipfs-cluster
- My IPFS-client uses too much memory
- You have enabled QUIC (version 0.5.x)
- My IPFS-client uses too much storage
- Enable GC
- Reduce the configured maximum disk space
- You're using the badger datastore
Clone this wiki locally
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.
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.
The currently recommended flags for the IPFS daemon are
--enable-gc --enable-pubsub-experiment --enable-namesys-pubsub.
enable-gcturns on the garbage collection. This functionality will remove all cached items when you're exceeding the configured cache size.
enable-namesys-pubsubturn on fast name-lookups, which are required for low latency download starts.
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).
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.
QUIC is currently not fully stable (thus being marked as experimental). It's recommended to disable QUIC for now (status: 0.5.1).
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.
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.
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: