go-ipfs-config: docs: updated flatfs/badger profile helptext (#167)
This is copy-paste from https://github.com/ipfs/go-ipfs/pull/8662 to ensure consistency.
Marcin Rataj committed
Jan 28, 2022 at 23:39 UTC
74e6436814a120f3aee802d89cc52bd3f798771d
1 file changed
+18
-16
config/profile.go
+18
-16
@@ -123,18 +123,16 @@ This profile may only be applied when first initializing the node.
123
"flatfs": {
124
Description: `Configures the node to use the flatfs datastore.
125
126
-This is the most battle-tested and reliable datastore, but it's significantly
127
-slower than the badger datastore. You should use this datastore if:
126
+This is the most battle-tested and reliable datastore.
127
+You should use this datastore if:
128
129
-* You need a very simple and very reliable datastore and you trust your
129
+* You need a very simple and very reliable datastore, and you trust your
130
filesystem. This datastore stores each block as a separate file in the
131
underlying filesystem so it's unlikely to loose data unless there's an issue
132
with the underlying file system.
133
-* You need to run garbage collection on a small (<= 10GiB) datastore. The
134
- default datastore, badger, can leave several gigabytes of data behind when
135
- garbage collecting.
136
-* You're concerned about memory usage. In its default configuration, badger can
137
- use up to several gigabytes of memory.
133
+* You need to run garbage collection in a way that reclaims free space as soon as possible.
134
+* You want to minimize memory usage.
135
+* You are ok with the default speed of data import, or prefer to use --nocopy.
136
137
This profile may only be applied when first initializing the node.
138
`,
@@ -146,17 +144,21 @@ This profile may only be applied when first initializing the node.
144
},
145
},
146
"badgerds": {
149
- Description: `Configures the node to use the badger datastore.
147
+ Description: `Configures the node to use the experimental badger datastore.
148
151
-This is the fastest datastore. Use this datastore if performance, especially
152
-when adding many gigabytes of files, is critical. However:
149
+Use this datastore if some aspects of performance,
150
+especially the speed of adding many gigabytes of files, are critical.
151
+However, be aware that:
152
153
* This datastore will not properly reclaim space when your datastore is
155
- smaller than several gigabytes. If you run IPFS with '--enable-gc' (you have
156
- enabled block-level garbage collection), you plan on storing very little data in
157
- your IPFS node, and disk usage is more critical than performance, consider using
158
- flatfs.
159
-* This datastore uses up to several gigabytes of memory.
154
+ smaller than several gigabytes. If you run IPFS with --enable-gc, you plan
155
+ on storing very little data in your IPFS node, and disk usage is more
156
+ critical than performance, consider using flatfs.
157
+* This datastore uses up to several gigabytes of memory.
158
+* Good for medium-size datastores, but may run into performance issues
159
+ if your dataset is bigger than a terabyte.
160
+* The current implementation is based on old badger 1.x
161
+ which is no longer supported by the upstream team.
162
163
This profile may only be applied when first initializing the node.`,
164