- Overview
- 🔦 Highlights
- Shared TCP listeners
- AutoTLS takes care of Secure WebSockets setup
- Bitswap improvements from Boxo
- Using default
libp2p_rcmgrmetrics - Flatfs does not
syncon each write ipfs add --to-filesno longer works with--wrap- New options for faster writes:
WriteThrough,BlockKeyCacheSize,BatchMaxNodes,BatchMaxSize - MFS stability with large number of writes
- 📦️ Important dependency updates
- 📝 Changelog
- 👨👩👧👦 Contributors
Kubo now supports sharing the same TCP port (4001 by default) by both raw TCP and WebSockets libp2p transports.
This feature is not yet compatible with Private Networks and can be disabled by setting LIBP2P_TCP_MUX=false if causes any issues.
It is no longer necessary to manually add /tcp/../ws listeners to Addresses.Swarm when AutoTLS.Enabled is set to true. Kubo will detect if /ws listener is missing and add one on the same port as pre-existing TCP (e.g. /tcp/4001), removing the need for any extra configuration.
Tip
Give it a try:
$ ipfs config --json AutoTLS.Enabled trueAnd restart the node. If you are behind NAT, make sure your node is publicly diallable (uPnP or port forwarding), and wait a few minutes to pass all checks and for the changes to take effect.
See AutoTLS for more information.
This release includes some refactorings and improvements affecting Bitswap which should improve reliability. One of the changes affects blocks providing. Previously, the bitswap layer took care itself of announcing new blocks -added or received- with the configured provider (i.e. DHT). This bypassed the "Reprovider", that is, the system that manages precisely "providing" the blocks stored by Kubo. The Reprovider knows how to take advantage of the AcceleratedDHTClient, is able to handle priorities, logs statistics and is able to resume on daemon reboot where it left off. From now on, Bitswap will not be doing any providing on-the-side and all announcements are managed by the reprovider. In some cases, when the reproviding queue is full with other elements, this may cause additional delays, but more likely this will result in improved block-providing behaviour overall.
Bespoke rcmgr metrics were removed, Kubo now exposes only the default libp2p_rcmgr metrics from go-libp2p.
This makes it easier to compare Kubo with custom implementations based on go-libp2p.
If you depended on removed ones, please fill an issue to add them to the upstream go-libp2p.
New repositories initialized with flatfs in Datastore.Spec will have sync set to false.
The old default was overly conservative and caused performance issues in big repositories that did a lot of writes. There is usually no need to flush on every block write to disk before continuing. Setting this to false is safe as kubo will automatically flush writes to disk before and after performing critical operations like pinning. However, we still provide users with ability to set this to true to be extra-safe (at the cost of a slowdown when adding files in bulk).
Onboarding files and directories with ipfs add --to-files now requires non-empty names. due to this, The --to-files and --wrap options are now mutually exclusive (#10612).
Now that Kubo supports pebble as a datastore backend, it becomes very useful to expose some additional configuration options for how the blockservice/blockstore/datastore combo behaves.
Usually, LSM-tree based datastore like Pebble or Badger have very fast write performance (blocks are streamed to disk) while incurring in read-amplification penalties (blocks need to be looked up in the index to know where they are on disk), specially noticiable on spinning disks.
Prior to this version, BlockService and Blockstore implementations performed a Has(cid) for every block that was going to be written, skipping the writes altogether if the block was already present in the datastore. The performance impact of this Has() call can vary. The Datastore implementation itself might include block-caching and things like bloom-filters to speed up lookups and mitigate read-penalties. Our Blockstore implementation also supports a bloom-filter (controlled by BloomFilterSize and disabled by default), and a two-queue cache for keys and block sizes. If we assume that most of the blocks added to Kubo are new blocks, not already present in the datastore, or that the datastore itself includes mechanisms to optimize writes and avoid writing the same data twice, the calls to Has() at both BlockService and Blockstore layers seem superflous to they point they even harm write performance.
For these reasons, from now on, the default is to use a "write-through" mode for the Blockservice and the Blockstore. We have added a new option Datastore.WriteThrough, which defaults to true. Previous behaviour can be obtained by manually setting it to false.
We have also made the size of the two-queue blockstore cache configurable with another option: Datastore.BlockKeyCacheSize, which defaults to 65536 (64KiB). Additionally, this caching layer can be disabled altogether by setting it to 0. In particular, this option controls the size of a blockstore caching layer that records whether the blockstore has certain block and their sizes (but does not cache the contents, so it stays relativey small in general).
Finally, we have added two new options to the Import section to control the maximum size of write-batches: BatchMaxNodes and BatchMaxSize. These are set by default to 128 nodes and 20MiB. Increasing them will batch more items together when importing data with ipfs dag import, which can speed things up. It is importance to find a balance between available memory (used to hold the batch), disk latencies (when writing the batch) and processing power (when preparing the batch, as nodes are sorted and duplicates removed).
As a reminder, details from all the options are explained in the configuration documentation.
We recommend users trying Pebble as a datastore backend to disable both blockstore bloom-filter and key caching layers and enable write through as a way to evaluate the raw performance of the underlying datastore, which includes its own bloom-filter and caching layers (default cache size is 8MiB and can be configured in the options.
We have fixed a number of issues that were triggered by writing or copying many files onto an MFS folder: increased memory usage first, then CPU, disk usage, and eventually a deadlock on write operations. The details of the fixes can be read at #10630 and #10623. The result is that writing large amounts of files to an MFS folder should now be possible without major issues. It is possible, as before, to speed up the operations using the ipfs files --flush=false <op> ... flag, but it is recommended to switch to ipfs files --flush=true <op> ... regularly, or call ipfs files flush on the working directory regularly, as this will flush, clear the directory cache and speed up reads.