chore: curio: remove forgotten parts of curio config (#12087)

This commit is contained in:
Peter Rabbitson 2024-06-14 03:34:36 +02:00 committed by GitHub
parent cea71aef51
commit 63b95779ce
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 1 additions and 812 deletions

View File

@ -147,8 +147,7 @@ jobs:
"itest-worker",
"multicore-sdr",
"unit-cli",
"unit-storage",
"itest-curio"
"unit-storage"
]
run: |
# Create a list of integration test groups

1
.gitignore vendored
View File

@ -6,7 +6,6 @@
/lotus-chainwatch
/lotus-shed
/lotus-sim
/curio
/sptool
/lotus-townhall
/lotus-fountain

View File

@ -117,509 +117,6 @@ your node if metadata log is disabled`,
Comment: ``,
},
},
"CurioAddresses": {
{
Name: "PreCommitControl",
Type: "[]string",
Comment: `Addresses to send PreCommit messages from`,
},
{
Name: "CommitControl",
Type: "[]string",
Comment: `Addresses to send Commit messages from`,
},
{
Name: "TerminateControl",
Type: "[]string",
Comment: ``,
},
{
Name: "DisableOwnerFallback",
Type: "bool",
Comment: `DisableOwnerFallback disables usage of the owner address for messages
sent automatically`,
},
{
Name: "DisableWorkerFallback",
Type: "bool",
Comment: `DisableWorkerFallback disables usage of the worker address for messages
sent automatically, if control addresses are configured.
A control address that doesn't have enough funds will still be chosen
over the worker address if this flag is set.`,
},
{
Name: "MinerAddresses",
Type: "[]string",
Comment: `MinerAddresses are the addresses of the miner actors to use for sending messages`,
},
},
"CurioAlerting": {
{
Name: "PagerDutyEventURL",
Type: "string",
Comment: `PagerDutyEventURL is URL for PagerDuty.com Events API v2 URL. Events sent to this API URL are ultimately
routed to a PagerDuty.com service and processed.
The default is sufficient for integration with the stock commercial PagerDuty.com company's service.`,
},
{
Name: "PageDutyIntegrationKey",
Type: "string",
Comment: `PageDutyIntegrationKey is the integration key for a PagerDuty.com service. You can find this unique service
identifier in the integration page for the service.`,
},
{
Name: "MinimumWalletBalance",
Type: "types.FIL",
Comment: `MinimumWalletBalance is the minimum balance all active wallets. If the balance is below this value, an
alerts will be triggered for the wallet`,
},
},
"CurioConfig": {
{
Name: "Subsystems",
Type: "CurioSubsystemsConfig",
Comment: ``,
},
{
Name: "Fees",
Type: "CurioFees",
Comment: ``,
},
{
Name: "Addresses",
Type: "[]CurioAddresses",
Comment: `Addresses of wallets per MinerAddress (one of the fields).`,
},
{
Name: "Proving",
Type: "CurioProvingConfig",
Comment: ``,
},
{
Name: "Ingest",
Type: "CurioIngestConfig",
Comment: ``,
},
{
Name: "Journal",
Type: "JournalConfig",
Comment: ``,
},
{
Name: "Apis",
Type: "ApisConfig",
Comment: ``,
},
{
Name: "Alerting",
Type: "CurioAlerting",
Comment: ``,
},
},
"CurioFees": {
{
Name: "DefaultMaxFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxPreCommitGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxCommitGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxPreCommitBatchGasFee",
Type: "BatchFeeConfig",
Comment: `maxBatchFee = maxBase + maxPerSector * nSectors`,
},
{
Name: "MaxCommitBatchGasFee",
Type: "BatchFeeConfig",
Comment: ``,
},
{
Name: "MaxTerminateGasFee",
Type: "types.FIL",
Comment: ``,
},
{
Name: "MaxWindowPoStGasFee",
Type: "types.FIL",
Comment: `WindowPoSt is a high-value operation, so the default fee should be high.`,
},
{
Name: "MaxPublishDealsFee",
Type: "types.FIL",
Comment: ``,
},
},
"CurioIngestConfig": {
{
Name: "MaxQueueSDR",
Type: "int",
Comment: `Maximum number of sectors that can be queued waiting for SDR to start processing.
0 = unlimited
Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
The SDR queue includes deals which are in the process of entering the sealing pipeline - size of this queue
will also impact the maximum number of ParkPiece tasks which can run concurrently.
SDR queue is the first queue in the sealing pipeline, meaning that it should be used as the primary backpressure mechanism.`,
},
{
Name: "MaxQueueTrees",
Type: "int",
Comment: `Maximum number of sectors that can be queued waiting for SDRTrees to start processing.
0 = unlimited
Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
In case of the trees tasks it is possible that this queue grows more than this limit, the backpressure is only
applied to sectors entering the pipeline.`,
},
{
Name: "MaxQueuePoRep",
Type: "int",
Comment: `Maximum number of sectors that can be queued waiting for PoRep to start processing.
0 = unlimited
Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
Like with the trees tasks, it is possible that this queue grows more than this limit, the backpressure is only
applied to sectors entering the pipeline.`,
},
},
"CurioProvingConfig": {
{
Name: "ParallelCheckLimit",
Type: "int",
Comment: `Maximum number of sector checks to run in parallel. (0 = unlimited)
WARNING: Setting this value too high may make the node crash by running out of stack
WARNING: Setting this value too low may make sector challenge reading much slower, resulting in failed PoSt due
to late submission.
After changing this option, confirm that the new value works in your setup by invoking
'lotus-miner proving compute window-post 0'`,
},
{
Name: "SingleCheckTimeout",
Type: "Duration",
Comment: `Maximum amount of time a proving pre-check can take for a sector. If the check times out the sector will be skipped
WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
test challenge took longer than this timeout
WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this sector are
blocked (e.g. in case of disconnected NFS mount)`,
},
{
Name: "PartitionCheckTimeout",
Type: "Duration",
Comment: `Maximum amount of time a proving pre-check can take for an entire partition. If the check times out, sectors in
the partition which didn't get checked on time will be skipped
WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
test challenge took longer than this timeout
WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this partition are
blocked or slow`,
},
{
Name: "DisableWDPoStPreChecks",
Type: "bool",
Comment: `Disable WindowPoSt provable sector readability checks.
In normal operation, when preparing to compute WindowPoSt, lotus-miner will perform a round of reading challenges
from all sectors to confirm that those sectors can be proven. Challenges read in this process are discarded, as
we're only interested in checking that sector data can be read.
When using builtin proof computation (no PoSt workers, and DisableBuiltinWindowPoSt is set to false), this process
can save a lot of time and compute resources in the case that some sectors are not readable - this is caused by
the builtin logic not skipping snark computation when some sectors need to be skipped.
When using PoSt workers, this process is mostly redundant, with PoSt workers challenges will be read once, and
if challenges for some sectors aren't readable, those sectors will just get skipped.
Disabling sector pre-checks will slightly reduce IO load when proving sectors, possibly resulting in shorter
time to produce window PoSt. In setups with good IO capabilities the effect of this option on proving time should
be negligible.
NOTE: It likely is a bad idea to disable sector pre-checks in setups with no PoSt workers.
NOTE: Even when this option is enabled, recovering sectors will be checked before recovery declaration message is
sent to the chain
After changing this option, confirm that the new value works in your setup by invoking
'lotus-miner proving compute window-post 0'`,
},
{
Name: "MaxPartitionsPerPoStMessage",
Type: "int",
Comment: `Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (3 in nv21)
A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors.
//
Note that setting this value lower may result in less efficient gas use - more messages will be sent,
to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
Setting this value above the network limit has no effect`,
},
{
Name: "MaxPartitionsPerRecoveryMessage",
Type: "int",
Comment: `In some cases when submitting DeclareFaultsRecovered messages,
there may be too many recoveries to fit in a BlockGasLimit.
In those cases it may be necessary to set this value to something low (eg 1);
Note that setting this value lower may result in less efficient gas use - more messages will be sent than needed,
resulting in more total gas use (but each message will have lower gas limit)`,
},
{
Name: "SingleRecoveringPartitionPerPostMessage",
Type: "bool",
Comment: `Enable single partition per PoSt Message for partitions containing recovery sectors
In cases when submitting PoSt messages which contain recovering sectors, the default network limit may still be
too high to fit in the block gas limit. In those cases, it becomes useful to only house the single partition
with recovering sectors in the post message
Note that setting this value lower may result in less efficient gas use - more messages will be sent,
to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)`,
},
},
"CurioSubsystemsConfig": {
{
Name: "EnableWindowPost",
Type: "bool",
Comment: `EnableWindowPost enables window post to be executed on this curio instance. Each machine in the cluster
with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple
machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline,
will allow for parallel processing of partitions.
It is possible to have instances handling both WindowPoSt and WinningPoSt, which can provide redundancy without
the need for additional machines. In setups like this it is generally recommended to run
partitionsPerDeadline+1 machines.`,
},
{
Name: "WindowPostMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableWinningPost",
Type: "bool",
Comment: `EnableWinningPost enables winning post to be executed on this curio instance.
Each machine in the cluster with WinningPoSt enabled will also participate in the winning post scheduler.
It is possible to mix machines with WindowPoSt and WinningPoSt enabled, for details see the EnableWindowPost
documentation.`,
},
{
Name: "WinningPostMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableParkPiece",
Type: "bool",
Comment: `EnableParkPiece enables the "piece parking" task to run on this node. This task is responsible for fetching
pieces from the network and storing them in the storage subsystem until sectors are sealed. This task is
only applicable when integrating with boost, and should be enabled on nodes which will hold deal data
from boost until sectors containing the related pieces have the TreeD/TreeR constructed.
Note that future Curio implementations will have a separate task type for fetching pieces from the internet.`,
},
{
Name: "ParkPieceMaxTasks",
Type: "int",
Comment: ``,
},
{
Name: "EnableSealSDR",
Type: "bool",
Comment: `EnableSealSDR enables SDR tasks to run. SDR is the long sequential computation
creating 11 layer files in sector cache directory.
SDR is the first task in the sealing pipeline. It's inputs are just the hash of the
unsealed data (CommD), sector number, miner id, and the seal proof type.
It's outputs are the 11 layer files in the sector cache directory.
In lotus-miner this was run as part of PreCommit1.`,
},
{
Name: "SealSDRMaxTasks",
Type: "int",
Comment: `The maximum amount of SDR tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "EnableSealSDRTrees",
Type: "bool",
Comment: `EnableSealSDRTrees enables the SDR pipeline tree-building task to run.
This task handles encoding of unsealed data into last sdr layer and building
of TreeR, TreeC and TreeD.
This task runs after SDR
TreeD is first computed with optional input of unsealed data
TreeR is computed from replica, which is first computed as field
addition of the last SDR layer and the bottom layer of TreeD (which is the unsealed data)
TreeC is computed from the 11 SDR layers
The 3 trees will later be used to compute the PoRep proof.
In case of SyntheticPoRep challenges for PoRep will be pre-generated at this step, and trees and layers
will be dropped. SyntheticPoRep works by pre-generating a very large set of challenges (~30GiB on disk)
then using a small subset of them for the actual PoRep computation. This allows for significant scratch space
saving between PreCommit and PoRep generation at the expense of more computation (generating challenges in this step)
In lotus-miner this was run as part of PreCommit2 (TreeD was run in PreCommit1).
Note that nodes with SDRTrees enabled will also answer to Finalize tasks,
which just remove unneeded tree data after PoRep is computed.`,
},
{
Name: "SealSDRTreesMaxTasks",
Type: "int",
Comment: `The maximum amount of SealSDRTrees tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "FinalizeMaxTasks",
Type: "int",
Comment: `FinalizeMaxTasks is the maximum amount of finalize tasks that can run simultaneously.
The finalize task is enabled on all machines which also handle SDRTrees tasks. Finalize ALWAYS runs on whichever
machine holds sector cache files, as it removes unneeded tree data after PoRep is computed.
Finalize will run in parallel with the SubmitCommitMsg task.`,
},
{
Name: "EnableSendPrecommitMsg",
Type: "bool",
Comment: `EnableSendPrecommitMsg enables the sending of precommit messages to the chain
from this curio instance.
This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message`,
},
{
Name: "EnablePoRepProof",
Type: "bool",
Comment: `EnablePoRepProof enables the computation of the porep proof
This task runs after interactive-porep seed becomes available, which happens 150 epochs (75min) after the
precommit message lands on chain. This task should run on a machine with a GPU. Vanilla PoRep proofs are
requested from the machine which holds sector cache files which most likely is the machine which ran the SDRTrees
task.
In lotus-miner this was Commit1 / Commit2`,
},
{
Name: "PoRepProofMaxTasks",
Type: "int",
Comment: `The maximum amount of PoRepProof tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine.`,
},
{
Name: "EnableSendCommitMsg",
Type: "bool",
Comment: `EnableSendCommitMsg enables the sending of commit messages to the chain
from this curio instance.`,
},
{
Name: "EnableMoveStorage",
Type: "bool",
Comment: `EnableMoveStorage enables the move-into-long-term-storage task to run on this curio instance.
This tasks should only be enabled on nodes with long-term storage.
The MoveStorage task is the last task in the sealing pipeline. It moves the sealed sector data from the
SDRTrees machine into long-term storage. This task runs after the Finalize task.`,
},
{
Name: "MoveStorageMaxTasks",
Type: "int",
Comment: `The maximum amount of MoveStorage tasks that can run simultaneously. Note that the maximum number of tasks will
also be bounded by resources available on the machine. It is recommended that this value is set to a number which
uses all available network (or disk) bandwidth on the machine without causing bottlenecks.`,
},
{
Name: "BoostAdapters",
Type: "[]string",
Comment: `BoostAdapters is a list of tuples of miner address and port/ip to listen for market (e.g. boost) requests.
This interface is compatible with the lotus-miner RPC, implementing a subset needed for storage market operations.
Strings should be in the format "actor:ip:port". IP cannot be 0.0.0.0. We recommend using a private IP.
Example: "f0123:127.0.0.1:32100". Multiple addresses can be specified.
When a market node like boost gives Curio's market RPC a deal to placing into a sector, Curio will first store the
deal data in a temporary location "Piece Park" before assigning it to a sector. This requires that at least one
node in the cluster has the EnableParkPiece option enabled and has sufficient scratch space to store the deal data.
This is different from lotus-miner which stored the deal data into an "unsealed" sector as soon as the deal was
received. Deal data in PiecePark is accessed when the sector TreeD and TreeR are computed, but isn't needed for
the initial SDR layers computation. Pieces in PiecePark are removed after all sectors referencing the piece are
sealed.
To get API info for boost configuration run 'curio market rpc-info'
NOTE: All deal data will flow through this service, so it should be placed on a machine running boost or on
a machine which handles ParkPiece tasks.`,
},
{
Name: "EnableWebGui",
Type: "bool",
Comment: `EnableWebGui enables the web GUI on this curio instance. The UI has minimal local overhead, but it should
only need to be run on a single machine in the cluster.`,
},
{
Name: "GuiAddress",
Type: "string",
Comment: `The address that should listen for Web GUI requests.`,
},
},
"DealmakingConfig": {
{
Name: "StartEpochSealingBuffer",

View File

@ -60,20 +60,6 @@ type StorageMiner struct {
HarmonyDB HarmonyDB
}
type CurioConfig struct {
Subsystems CurioSubsystemsConfig
Fees CurioFees
// Addresses of wallets per MinerAddress (one of the fields).
Addresses []CurioAddresses
Proving CurioProvingConfig
Ingest CurioIngestConfig
Journal JournalConfig
Apis ApisConfig
Alerting CurioAlerting
}
type ApisConfig struct {
// ChainApiInfo is the API endpoint for the Lotus daemon.
ChainApiInfo []string
@ -89,140 +75,6 @@ type JournalConfig struct {
DisabledEvents string
}
type CurioSubsystemsConfig struct {
// EnableWindowPost enables window post to be executed on this curio instance. Each machine in the cluster
// with WindowPoSt enabled will also participate in the window post scheduler. It is possible to have multiple
// machines with WindowPoSt enabled which will provide redundancy, and in case of multiple partitions per deadline,
// will allow for parallel processing of partitions.
//
// It is possible to have instances handling both WindowPoSt and WinningPoSt, which can provide redundancy without
// the need for additional machines. In setups like this it is generally recommended to run
// partitionsPerDeadline+1 machines.
EnableWindowPost bool
WindowPostMaxTasks int
// EnableWinningPost enables winning post to be executed on this curio instance.
// Each machine in the cluster with WinningPoSt enabled will also participate in the winning post scheduler.
// It is possible to mix machines with WindowPoSt and WinningPoSt enabled, for details see the EnableWindowPost
// documentation.
EnableWinningPost bool
WinningPostMaxTasks int
// EnableParkPiece enables the "piece parking" task to run on this node. This task is responsible for fetching
// pieces from the network and storing them in the storage subsystem until sectors are sealed. This task is
// only applicable when integrating with boost, and should be enabled on nodes which will hold deal data
// from boost until sectors containing the related pieces have the TreeD/TreeR constructed.
// Note that future Curio implementations will have a separate task type for fetching pieces from the internet.
EnableParkPiece bool
ParkPieceMaxTasks int
// EnableSealSDR enables SDR tasks to run. SDR is the long sequential computation
// creating 11 layer files in sector cache directory.
//
// SDR is the first task in the sealing pipeline. It's inputs are just the hash of the
// unsealed data (CommD), sector number, miner id, and the seal proof type.
// It's outputs are the 11 layer files in the sector cache directory.
//
// In lotus-miner this was run as part of PreCommit1.
EnableSealSDR bool
// The maximum amount of SDR tasks that can run simultaneously. Note that the maximum number of tasks will
// also be bounded by resources available on the machine.
SealSDRMaxTasks int
// EnableSealSDRTrees enables the SDR pipeline tree-building task to run.
// This task handles encoding of unsealed data into last sdr layer and building
// of TreeR, TreeC and TreeD.
//
// This task runs after SDR
// TreeD is first computed with optional input of unsealed data
// TreeR is computed from replica, which is first computed as field
// addition of the last SDR layer and the bottom layer of TreeD (which is the unsealed data)
// TreeC is computed from the 11 SDR layers
// The 3 trees will later be used to compute the PoRep proof.
//
// In case of SyntheticPoRep challenges for PoRep will be pre-generated at this step, and trees and layers
// will be dropped. SyntheticPoRep works by pre-generating a very large set of challenges (~30GiB on disk)
// then using a small subset of them for the actual PoRep computation. This allows for significant scratch space
// saving between PreCommit and PoRep generation at the expense of more computation (generating challenges in this step)
//
// In lotus-miner this was run as part of PreCommit2 (TreeD was run in PreCommit1).
// Note that nodes with SDRTrees enabled will also answer to Finalize tasks,
// which just remove unneeded tree data after PoRep is computed.
EnableSealSDRTrees bool
// The maximum amount of SealSDRTrees tasks that can run simultaneously. Note that the maximum number of tasks will
// also be bounded by resources available on the machine.
SealSDRTreesMaxTasks int
// FinalizeMaxTasks is the maximum amount of finalize tasks that can run simultaneously.
// The finalize task is enabled on all machines which also handle SDRTrees tasks. Finalize ALWAYS runs on whichever
// machine holds sector cache files, as it removes unneeded tree data after PoRep is computed.
// Finalize will run in parallel with the SubmitCommitMsg task.
FinalizeMaxTasks int
// EnableSendPrecommitMsg enables the sending of precommit messages to the chain
// from this curio instance.
// This runs after SDRTrees and uses the output CommD / CommR (roots of TreeD / TreeR) for the message
EnableSendPrecommitMsg bool
// EnablePoRepProof enables the computation of the porep proof
//
// This task runs after interactive-porep seed becomes available, which happens 150 epochs (75min) after the
// precommit message lands on chain. This task should run on a machine with a GPU. Vanilla PoRep proofs are
// requested from the machine which holds sector cache files which most likely is the machine which ran the SDRTrees
// task.
//
// In lotus-miner this was Commit1 / Commit2
EnablePoRepProof bool
// The maximum amount of PoRepProof tasks that can run simultaneously. Note that the maximum number of tasks will
// also be bounded by resources available on the machine.
PoRepProofMaxTasks int
// EnableSendCommitMsg enables the sending of commit messages to the chain
// from this curio instance.
EnableSendCommitMsg bool
// EnableMoveStorage enables the move-into-long-term-storage task to run on this curio instance.
// This tasks should only be enabled on nodes with long-term storage.
//
// The MoveStorage task is the last task in the sealing pipeline. It moves the sealed sector data from the
// SDRTrees machine into long-term storage. This task runs after the Finalize task.
EnableMoveStorage bool
// The maximum amount of MoveStorage tasks that can run simultaneously. Note that the maximum number of tasks will
// also be bounded by resources available on the machine. It is recommended that this value is set to a number which
// uses all available network (or disk) bandwidth on the machine without causing bottlenecks.
MoveStorageMaxTasks int
// BoostAdapters is a list of tuples of miner address and port/ip to listen for market (e.g. boost) requests.
// This interface is compatible with the lotus-miner RPC, implementing a subset needed for storage market operations.
// Strings should be in the format "actor:ip:port". IP cannot be 0.0.0.0. We recommend using a private IP.
// Example: "f0123:127.0.0.1:32100". Multiple addresses can be specified.
//
// When a market node like boost gives Curio's market RPC a deal to placing into a sector, Curio will first store the
// deal data in a temporary location "Piece Park" before assigning it to a sector. This requires that at least one
// node in the cluster has the EnableParkPiece option enabled and has sufficient scratch space to store the deal data.
// This is different from lotus-miner which stored the deal data into an "unsealed" sector as soon as the deal was
// received. Deal data in PiecePark is accessed when the sector TreeD and TreeR are computed, but isn't needed for
// the initial SDR layers computation. Pieces in PiecePark are removed after all sectors referencing the piece are
// sealed.
//
// To get API info for boost configuration run 'curio market rpc-info'
//
// NOTE: All deal data will flow through this service, so it should be placed on a machine running boost or on
// a machine which handles ParkPiece tasks.
BoostAdapters []string
// EnableWebGui enables the web GUI on this curio instance. The UI has minimal local overhead, but it should
// only need to be run on a single machine in the cluster.
EnableWebGui bool
// The address that should listen for Web GUI requests.
GuiAddress string
}
type MinerSubsystemConfig struct {
EnableMining bool
EnableSealing bool
@ -543,20 +395,6 @@ type MinerFeeConfig struct {
MaximizeWindowPoStFeeCap bool
}
type CurioFees struct {
DefaultMaxFee types.FIL
MaxPreCommitGasFee types.FIL
MaxCommitGasFee types.FIL
// maxBatchFee = maxBase + maxPerSector * nSectors
MaxPreCommitBatchGasFee BatchFeeConfig
MaxCommitBatchGasFee BatchFeeConfig
MaxTerminateGasFee types.FIL
// WindowPoSt is a high-value operation, so the default fee should be high.
MaxWindowPoStGasFee types.FIL
MaxPublishDealsFee types.FIL
}
type MinerAddressConfig struct {
// Addresses to send PreCommit messages from
PreCommitControl []string
@ -575,135 +413,6 @@ type MinerAddressConfig struct {
DisableWorkerFallback bool
}
type CurioAddresses struct {
// Addresses to send PreCommit messages from
PreCommitControl []string
// Addresses to send Commit messages from
CommitControl []string
TerminateControl []string
// DisableOwnerFallback disables usage of the owner address for messages
// sent automatically
DisableOwnerFallback bool
// DisableWorkerFallback disables usage of the worker address for messages
// sent automatically, if control addresses are configured.
// A control address that doesn't have enough funds will still be chosen
// over the worker address if this flag is set.
DisableWorkerFallback bool
// MinerAddresses are the addresses of the miner actors to use for sending messages
MinerAddresses []string
}
type CurioProvingConfig struct {
// Maximum number of sector checks to run in parallel. (0 = unlimited)
//
// WARNING: Setting this value too high may make the node crash by running out of stack
// WARNING: Setting this value too low may make sector challenge reading much slower, resulting in failed PoSt due
// to late submission.
//
// After changing this option, confirm that the new value works in your setup by invoking
// 'lotus-miner proving compute window-post 0'
ParallelCheckLimit int
// Maximum amount of time a proving pre-check can take for a sector. If the check times out the sector will be skipped
//
// WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
// test challenge took longer than this timeout
// WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this sector are
// blocked (e.g. in case of disconnected NFS mount)
SingleCheckTimeout Duration
// Maximum amount of time a proving pre-check can take for an entire partition. If the check times out, sectors in
// the partition which didn't get checked on time will be skipped
//
// WARNING: Setting this value too low risks in sectors being skipped even though they are accessible, just reading the
// test challenge took longer than this timeout
// WARNING: Setting this value too high risks missing PoSt deadline in case IO operations related to this partition are
// blocked or slow
PartitionCheckTimeout Duration
// Disable WindowPoSt provable sector readability checks.
//
// In normal operation, when preparing to compute WindowPoSt, lotus-miner will perform a round of reading challenges
// from all sectors to confirm that those sectors can be proven. Challenges read in this process are discarded, as
// we're only interested in checking that sector data can be read.
//
// When using builtin proof computation (no PoSt workers, and DisableBuiltinWindowPoSt is set to false), this process
// can save a lot of time and compute resources in the case that some sectors are not readable - this is caused by
// the builtin logic not skipping snark computation when some sectors need to be skipped.
//
// When using PoSt workers, this process is mostly redundant, with PoSt workers challenges will be read once, and
// if challenges for some sectors aren't readable, those sectors will just get skipped.
//
// Disabling sector pre-checks will slightly reduce IO load when proving sectors, possibly resulting in shorter
// time to produce window PoSt. In setups with good IO capabilities the effect of this option on proving time should
// be negligible.
//
// NOTE: It likely is a bad idea to disable sector pre-checks in setups with no PoSt workers.
//
// NOTE: Even when this option is enabled, recovering sectors will be checked before recovery declaration message is
// sent to the chain
//
// After changing this option, confirm that the new value works in your setup by invoking
// 'lotus-miner proving compute window-post 0'
DisableWDPoStPreChecks bool
// Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (3 in nv21)
//
// A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors.
// //
// Note that setting this value lower may result in less efficient gas use - more messages will be sent,
// to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
//
// Setting this value above the network limit has no effect
MaxPartitionsPerPoStMessage int
// Maximum number of partitions to declare in a single DeclareFaultsRecovered message. 0 = no limit.
// In some cases when submitting DeclareFaultsRecovered messages,
// there may be too many recoveries to fit in a BlockGasLimit.
// In those cases it may be necessary to set this value to something low (eg 1);
// Note that setting this value lower may result in less efficient gas use - more messages will be sent than needed,
// resulting in more total gas use (but each message will have lower gas limit)
MaxPartitionsPerRecoveryMessage int
// Enable single partition per PoSt Message for partitions containing recovery sectors
//
// In cases when submitting PoSt messages which contain recovering sectors, the default network limit may still be
// too high to fit in the block gas limit. In those cases, it becomes useful to only house the single partition
// with recovering sectors in the post message
//
// Note that setting this value lower may result in less efficient gas use - more messages will be sent,
// to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
SingleRecoveringPartitionPerPostMessage bool
}
type CurioIngestConfig struct {
// Maximum number of sectors that can be queued waiting for SDR to start processing.
// 0 = unlimited
// Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
// The SDR queue includes deals which are in the process of entering the sealing pipeline - size of this queue
// will also impact the maximum number of ParkPiece tasks which can run concurrently.
//
// SDR queue is the first queue in the sealing pipeline, meaning that it should be used as the primary backpressure mechanism.
MaxQueueSDR int
// Maximum number of sectors that can be queued waiting for SDRTrees to start processing.
// 0 = unlimited
// Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
// In case of the trees tasks it is possible that this queue grows more than this limit, the backpressure is only
// applied to sectors entering the pipeline.
MaxQueueTrees int
// Maximum number of sectors that can be queued waiting for PoRep to start processing.
// 0 = unlimited
// Note: This mechanism will delay taking deal data from markets, providing backpressure to the market subsystem.
// Like with the trees tasks, it is possible that this queue grows more than this limit, the backpressure is only
// applied to sectors entering the pipeline.
MaxQueuePoRep int
}
// API contains configs for API endpoint
type API struct {
// Binding address for the Lotus API
@ -947,18 +656,3 @@ type FaultReporterConfig struct {
// rewards. This address should have adequate funds to cover gas fees.
ConsensusFaultReporterAddress string
}
type CurioAlerting struct {
// PagerDutyEventURL is URL for PagerDuty.com Events API v2 URL. Events sent to this API URL are ultimately
// routed to a PagerDuty.com service and processed.
// The default is sufficient for integration with the stock commercial PagerDuty.com company's service.
PagerDutyEventURL string
// PageDutyIntegrationKey is the integration key for a PagerDuty.com service. You can find this unique service
// identifier in the integration page for the service.
PageDutyIntegrationKey string
// MinimumWalletBalance is the minimum balance all active wallets. If the balance is below this value, an
// alerts will be triggered for the wallet
MinimumWalletBalance types.FIL
}