docs: update badger section in config.md (#8662)
This should fix the issue of users thinking badger is "no-brainer faster choice" and then running into problems. Co-authored-by: Johnny <9611008+johnnymatthews@users.noreply.github.com>
Marcin Rataj committed
Jan 28, 2022 at 23:22 UTC
4ad316803e8cfcdc83d44d93a67e799312a8bc6b
1 file changed
+16
-17
docs/config.md
+16
-17
@@ -188,37 +188,36 @@ documented in `ipfs config profile --help`.
188
189
- `flatfs`
190
191
- Configures the node to use the flatfs datastore.
191
+ Configures the node to use the flatfs datastore. Flatfs is the default datastore.
192
193
- This is the most battle-tested and reliable datastore, but it's significantly
194
- slower than the badger datastore. You should use this datastore if:
193
+ This is the most battle-tested and reliable datastore.
194
+ You should use this datastore if:
195
196
- - You need a very simple and very reliable datastore and you trust your
196
+ - You need a very simple and very reliable datastore, and you trust your
197
filesystem. This datastore stores each block as a separate file in the
198
underlying filesystem so it's unlikely to lose data unless there's an issue
199
with the underlying file system.
200
- - You need to run garbage collection on a small (<= 10GiB) datastore. The
201
- default datastore, badger, can leave several gigabytes of data behind when
202
- garbage collecting.
203
- - You're concerned about memory usage. In its default configuration, badger can
204
- use up to several gigabytes of memory.
200
+ - You need to run garbage collection in a way that reclaims free space as soon as possible.
201
+ - You want to minimize memory usage.
202
+ - You are ok with the default speed of data import, or prefer to use `--nocopy`.
203
204
This profile may only be applied when first initializing the node.
205
206
207
- `badgerds`
208
211
- Configures the node to use the badger datastore.
212
-
213
- This is the fastest datastore. Use this datastore if performance, especially
214
- when adding many gigabytes of files, is critical. However:
209
+ Configures the node to use the experimental badger datastore. Keep in mind that this **uses an outdated badger 1.x**.
210
211
+ Use this datastore if some aspects of performance,
212
+ especially the speed of adding many gigabytes of files, are critical. However, be aware that:
213
+
214
- This datastore will not properly reclaim space when your datastore is
217
- smaller than several gigabytes. If you run IPFS with '--enable-gc' (you have
218
- enabled block-level garbage collection), you plan on storing very little data in
215
+ smaller than several gigabytes. If you run IPFS with `--enable-gc`, you plan on storing very little data in
216
your IPFS node, and disk usage is more critical than performance, consider using
220
- flatfs.
221
- - This datastore uses up to several gigabytes of memory.
217
+ `flatfs`.
218
+ - This datastore uses up to several gigabytes of memory.
219
+ - Good for medium-size datastores, but may run into performance issues if your dataset is bigger than a terabyte.
220
+ - The current implementation is based on old badger 1.x which is no longer supported by the upstream team.
221
222
This profile may only be applied when first initializing the node.
223