cd2fe8f655
Because we are adding blocks on a single call, and we choose the format parameter based on the prefix of the first block, IPFS will return block CIDs based on that option. This caused warnings when adding content that has multiple CID prefixes: for example, any cid-version=1 file will include both dag-pb CIDs and raw CIDs. Since the first block is usually a leave, IPFS will only return raw-cids, and cause a warning because of the CID-mistmatch. This fixes things by comparing multihashes only. But! We might be writing blocks with the wrong CID and then the good CID won't work! Correct, we might, in some corner cases. In go-ipfs >= 0.12.0, all blocks are addressed by multihash so CID prefixes are irrelevant. This problem does not exist in that case. In go-ipfs < 0.12.0, if a read for a CIDv1 DAG-PB fails, it is retried as it it was raw. This means that if we wrote something with cidv1/format=raw, that should have been a cidv1/format=dag-pb, the read will still work. That covers some common cases (i.e. adding with cid-version=1) because the first block should be a raw-leaf. Default-params (cidv0) is not affected since everything is raw multihashes. However, there are still possible CAR layouts etc. where cluster will write blocks wrongly to older IPFS versions. |
||
---|---|---|
.github | ||
adder | ||
allocator/balanced | ||
api | ||
cmd | ||
cmdutils | ||
config | ||
consensus | ||
datastore | ||
docker | ||
informer | ||
ipfsconn/ipfshttp | ||
monitor | ||
observations | ||
pintracker | ||
pstoremgr | ||
rpcutil | ||
sharness | ||
state | ||
test | ||
version | ||
.codeclimate.yml | ||
.codecov.yml | ||
.dockerignore | ||
.gitignore | ||
add_test.go | ||
allocate.go | ||
CHANGELOG.md | ||
cluster_config_test.go | ||
cluster_config.go | ||
cluster_test.go | ||
cluster.go | ||
clusterhost.go | ||
config_test.go | ||
connect_graph.go | ||
CONTRIBUTING.md | ||
COPYRIGHT | ||
docker-compose.yml | ||
Dockerfile | ||
Dockerfile-bundle | ||
Dockerfile-test | ||
go.mod | ||
go.sum | ||
ipfscluster_test.go | ||
ipfscluster.go | ||
LICENSE | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
logging.go | ||
Makefile | ||
peer_manager_test.go | ||
pnet_test.go | ||
README.md | ||
release.sh | ||
rpc_api.go | ||
rpc_policy.go | ||
util.go |
IPFS Cluster
Automated data availability and redundancy on IPFS
IPFS Cluster provides data orchestration across a swarm of IPFS daemons by allocating, replicating and tracking a global pinset distributed among multiple peers.
It provides:
- A cluster peer application:
ipfs-cluster-service
, to be run along withgo-ipfs
. - A client CLI application:
ipfs-cluster-ctl
, which allows easily interacting with the peer's HTTP API. - An additional "follower" peer application:
ipfs-cluster-follow
, focused on simplifying the process of configuring and running follower peers.
Are you using IPFS Cluster?
Please participate in the IPFS Cluster user registry.
Table of Contents
Documentation
Please visit https://cluster.ipfs.io/documentation/ to access user documentation, guides and any other resources, including detailed download and usage instructions.
News & Roadmap
We regularly post project updates to https://cluster.ipfs.io/news/ .
The most up-to-date Roadmap is available at https://cluster.ipfs.io/roadmap/ .
Install
Instructions for different installation methods (including from source) are available at https://cluster.ipfs.io/download .
Usage
Extensive usage information is provided at https://cluster.ipfs.io/documentation/ , including:
Contribute
PRs accepted. As part of the IPFS project, we have some contribution guidelines.
License
This library is dual-licensed under Apache 2.0 and MIT terms.
© 2020. Protocol Labs, Inc.