diff --git a/LOTUS_RELEASE_FLOW.md b/LOTUS_RELEASE_FLOW.md index d4e77faf732..5a307a3a57b 100644 --- a/LOTUS_RELEASE_FLOW.md +++ b/LOTUS_RELEASE_FLOW.md @@ -96,7 +96,7 @@ The specific steps executed for Lotus software releases are captured in the [Rel ## Release Candidates (RCs) - For regular (i.e., no critical security patch) releases with no accompanying network upgrade, the RC period is typically around 1 week. -- For releases accompanying network upgrades, the release candiadte period is a lot longer to allow for more extensive testing, usually around 5 to 6 weeks. +- For releases accompanying network upgrades, the release candidate period is a lot longer to allow for more extensive testing, usually around 5 to 6 weeks. - Releases rushing out a critical security patch will likely have an RC period on the order of hours or days, or may even forgo the RC phase. To compensate for the release speed, these releases will include the minimum delta necessary, meaning they'll be a patch on top of an existing release rather than taking the latest changes in the `master` branch. ## Security Fix Policy diff --git a/chain/types/tipset_key.go b/chain/types/tipset_key.go index 703ff2a4c43..81a9795717d 100644 --- a/chain/types/tipset_key.go +++ b/chain/types/tipset_key.go @@ -37,7 +37,7 @@ func init() { type TipSetKey struct { // The internal representation is a concatenation of the bytes of the CIDs, which are // self-describing, wrapped as a string. - // These gymnastics make the a TipSetKey usable as a map key. + // These gymnastics make a TipSetKey usable as a map key. // The empty key has value "". value string } diff --git a/cli/backup.go b/cli/backup.go index e0495678cfd..c5122f57c67 100644 --- a/cli/backup.go +++ b/cli/backup.go @@ -112,7 +112,7 @@ func BackupCmd(repoFlag string, rt repo.RepoType, getApi BackupApiFn) *cli.Comma Description: `The backup command writes a copy of node metadata under the specified path Online backups: -For security reasons, the daemon must be have LOTUS_BACKUP_BASE_PATH env var set +For security reasons, the daemon must have LOTUS_BACKUP_BASE_PATH env var set to a path where backup files are supposed to be saved, and the path specified in this command must be within this base path`, Flags: []cli.Flag{ diff --git a/documentation/en/chain-indexer-overview-for-operators.md b/documentation/en/chain-indexer-overview-for-operators.md index cafa24872dc..1c6e3a238a5 100644 --- a/documentation/en/chain-indexer-overview-for-operators.md +++ b/documentation/en/chain-indexer-overview-for-operators.md @@ -212,7 +212,7 @@ There is no automated migration from [pre-ChainIndexer indices](#previous-indexi ### Backfill Timing -Backfilling the new `ChainIndexer` was [benchmarked to take approximately ~12 hours per month of epochs on a sample archival node doing no other work](https://github.com/filecoin-project/lotus/issues/12453#issuecomment-2405306468). Your results will vary depending on hardware, network, and competing processes. This means if one is upgrading a FEVM archival node, they should plan on the node being out of production service for ~10 days. Additional nodes to update don't need to go throuh the same time-intensive process though. They can get a `${LOTUS_PATH}/chainindex/chainindex.db` copied from a trusted node per the [upgrade steps](#upgrade). +Backfilling the new `ChainIndexer` was [benchmarked to take approximately ~12 hours per month of epochs on a sample archival node doing no other work](https://github.com/filecoin-project/lotus/issues/12453#issuecomment-2405306468). Your results will vary depending on hardware, network, and competing processes. This means if one is upgrading a FEVM archival node, they should plan on the node being out of production service for ~10 days. Additional nodes to update don't need to go through the same time-intensive process though. They can get a `${LOTUS_PATH}/chainindex/chainindex.db` copied from a trusted node per the [upgrade steps](#upgrade). ### Backfill Disk Space Requirements @@ -318,7 +318,7 @@ In case you need to downgrade to the [previous indexing system](#previous-indexi The decision to not invest here ultimately comes down to the development-time cost vs. benefit ratio. -For achival nodes, we don't have the confidence that the [previous indexing system](#previous-indexing-system) has the correct data to bootstrap from. In 2024, Lotus maintainers have fixed multiple bugs in the [previous indexing system](#previous-indexing-system), but they still see reports of missing data, mismatched event index counts, etc. Investing here in a migration isn't guaranteed to yield a correct index. As a result, one would still need to perform the [backfill steps](#backfill) to validate and correct the data anyway. While this should be faster having partially correct data than no data, it would still require an archival node to take an outage on the order of days which isn't good enough. +For archival nodes, we don't have the confidence that the [previous indexing system](#previous-indexing-system) has the correct data to bootstrap from. In 2024, Lotus maintainers have fixed multiple bugs in the [previous indexing system](#previous-indexing-system), but they still see reports of missing data, mismatched event index counts, etc. Investing here in a migration isn't guaranteed to yield a correct index. As a result, one would still need to perform the [backfill steps](#backfill) to validate and correct the data anyway. While this should be faster having partially correct data than no data, it would still require an archival node to take an outage on the order of days which isn't good enough. The schemas of [the old fragmented Indices](#previous-indexing-system) don't naturally map to the schema of the [ChainIndexer](#chainindexer-indexing-system). There would be additional data wrangling work to ultimately get this right. diff --git a/documentation/en/cli-lotus-miner.md b/documentation/en/cli-lotus-miner.md index da3913a14a1..ff427ea09e9 100644 --- a/documentation/en/cli-lotus-miner.md +++ b/documentation/en/cli-lotus-miner.md @@ -176,7 +176,7 @@ DESCRIPTION: The backup command writes a copy of node metadata under the specified path Online backups: - For security reasons, the daemon must be have LOTUS_BACKUP_BASE_PATH env var set + For security reasons, the daemon must have LOTUS_BACKUP_BASE_PATH env var set to a path where backup files are supposed to be saved, and the path specified in this command must be within this base path diff --git a/documentation/en/cli-lotus.md b/documentation/en/cli-lotus.md index 08e252714e5..748f7f62621 100644 --- a/documentation/en/cli-lotus.md +++ b/documentation/en/cli-lotus.md @@ -107,7 +107,7 @@ DESCRIPTION: The backup command writes a copy of node metadata under the specified path Online backups: - For security reasons, the daemon must be have LOTUS_BACKUP_BASE_PATH env var set + For security reasons, the daemon must have LOTUS_BACKUP_BASE_PATH env var set to a path where backup files are supposed to be saved, and the path specified in this command must be within this base path