You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: core/node/bitswap.go
+6-3Lines changed: 6 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,7 @@ const (
28
28
DefaultEngineTaskWorkerCount=8
29
29
DefaultMaxOutstandingBytesPerPeer=1<<20
30
30
DefaultProviderSearchDelay=1000*time.Millisecond
31
+
DefaultMaxProviders=10// matching BitswapClientDefaultMaxProviders from https://github.com/ipfs/boxo/blob/v0.29.1/bitswap/internal/defaults/defaults.go#L15
The [Mutable File System (MFS)](https://docs.ipfs.tech/concepts/glossary/#mfs) in Kubo is a UnixFS filesystem managed with [`ipfs files`](https://docs.ipfs.tech/reference/kubo/cli/#ipfs-files) commands. It supports familiar file operations like cp and mv within a folder-tree structure, automatically updating a MerkleDAG and a "root CID" that reflects the current MFS state. Files in MFS are protected from garbage collection, offering a simpler alternative to `ipfs pin`. This makes it a popular choice for tools like [IPFS Desktop](https://docs.ipfs.tech/install/ipfs-desktop/) and the [WebUI](https://github.com/ipfs/ipfs-webui/#readme).
31
+
32
+
Previously, the `pinned` reprovider strategy required manual pin management: each dataset update meant pinning the new version and unpinning the old one. Now, new strategies—`mfs` and `pinned+mfs`—let users limit announcements to data explicitly placed in MFS. This simplifies updating datasets and announcing only the latest version to the Amino DHT.
33
+
34
+
Users relying on the `pinned` strategy can switch to `pinned+mfs` and use MFS alone to manage updates and announcements, eliminating the need for manual pinning and unpinning. We hope this makes it easier to publish just the data that matters to you.
35
+
36
+
See [`Reprovider.Strategy`](https://github.com/ipfs/kubo/blob/master/docs/config.md#reproviderstrategy) for more details.
37
+
38
+
#### Additional new configuration options
39
+
40
+
-[`Internal.Bitswap.ProviderSearchMaxResults`](https://github.com/ipfs/kubo/blob/master/docs/config.md##internalbitswapprovidersearchmaxresults) for adjusting the maximum number of providers bitswap client should aim at before it stops searching for new ones.
41
+
-[`Routing.IgnoreProviders`](https://github.com/ipfs/kubo/blob/master/docs/config.md#routingignoreproviders) allows ignoring specific peer IDs when returned by the content routing system as providers of content.
42
+
43
+
#### Grid view in WebUI
44
+
45
+
The WebUI, accessible at http://127.0.0.1:5001/webui/, now includes support for the grid view on the _Files_ screen:
@@ -1185,14 +1186,21 @@ deteriorate the quality provided to less aggressively-wanting peers.
1185
1186
1186
1187
Type: `optionalInteger` (byte count, `null` means default which is 1MB)
1187
1188
1188
-
### `Internal.Bitswap.ProviderSearchDelay`
1189
+
####`Internal.Bitswap.ProviderSearchDelay`
1189
1190
1190
1191
This parameter determines how long to wait before looking for providers outside of bitswap.
1191
1192
Other routing systems like the Amino DHT are able to provide results in less than a second, so lowering
1192
1193
this number will allow faster peers lookups in some cases.
1193
1194
1194
1195
Type: `optionalDuration` (`null` means default which is 1s)
1195
1196
1197
+
#### `Internal.Bitswap.ProviderSearchMaxResults`
1198
+
1199
+
Maximum number of providers bitswap client should aim at before it stops searching for new ones.
1200
+
Setting to 0 means unlimited.
1201
+
1202
+
Type: `optionalInteger` (`null` means default which is 10)
1203
+
1196
1204
### `Internal.UnixFSShardingSizeThreshold`
1197
1205
1198
1206
**MOVED:** see [`Import.UnixFSHAMTDirectorySizeThreshold`](#importunixfshamtdirectorysizethreshold)
@@ -1583,21 +1591,26 @@ Type: `optionalDuration` (unset for the default)
1583
1591
Tells reprovider what should be announced. Valid strategies are:
1584
1592
1585
1593
-`"all"` - announce all CIDs of stored blocks
1586
-
- Order: root blocks of direct and recursive pins are announced first, then the rest of blockstore
1587
-
-`"pinned"` - only announce pinned CIDs recursively (both roots and child blocks)
1594
+
- Order: root blocks of direct and recursive pins and MFS root are announced first, then the rest of blockstore
1595
+
-`"pinned"` - only announce recursively pinned CIDs (`ipfs pin add -r`, both roots and child blocks)
1588
1596
- Order: root blocks of direct and recursive pins are announced first, then the child blocks of recursive pins
1589
-
-`"roots"` - only announce the root block of explicitly pinned CIDs
1597
+
-`"roots"` - only announce the root block of explicitly pinned CIDs (`ipfs pin add`)
1590
1598
-**⚠️ BE CAREFUL:** node with `roots` strategy will not announce child blocks.
1591
1599
It makes sense only for use cases where the entire DAG is fetched in full,
1592
1600
and a graceful resume does not have to be guaranteed: the lack of child
1593
1601
announcements means an interrupted retrieval won't be able to find
1594
1602
providers for the missing block in the middle of a file, unless the peer
1595
1603
happens to already be connected to a provider and ask for child CID over
1596
1604
bitswap.
1605
+
-`"mfs"` - announce only the local CIDs that are part of the MFS (`ipfs files`)
1606
+
- Note: MFS is lazy-loaded. Only the MFS blocks present in local datastore are announced.
1607
+
-`"pinned+mfs"` - a combination of the `pinned` and `mfs` strategies.
1608
+
-**ℹ️ NOTE:** This is the suggested strategy for users who run without GC and don't want to provide everything in cache.
1609
+
- Order: first `pinned` and then the locally available part of `mfs`.
1597
1610
-`"flat"` - same as `all`, announce all CIDs of stored blocks, but without prioritizing anything.
1598
1611
1599
1612
> [!IMPORTANT]
1600
-
> Reproviding larger pinsets using the `all`, `pinned`, or `roots` strategies requires additional memory, with an estimated ~1 GiB of RAM per 20 million items for reproviding to the Amino DHT.
1613
+
> Reproviding larger pinsets using the `all`, `mfs`, `pinned`,`pinned+mfs` or `roots` strategies requires additional memory, with an estimated ~1 GiB of RAM per 20 million items for reproviding to the Amino DHT.
1601
1614
> This is due to the use of a buffered provider, which avoids holding a lock on the entire pinset during the reprovide cycle.
1602
1615
> The `flat` strategy can be used to lower memory requirements, but only recommended if memory utilization is too high, prioritization of pins is not necessary, and it is acceptable to announce every block cached in the local repository.
0 commit comments