-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Util for miners to extend all v1 sectors #5924
Conversation
67e7b44
to
ced47ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No blocking changes (fine to approve as-is) but we could make this slightly nicer.
cmd/lotus-storage-miner/sectors.go
Outdated
if cctx.Bool("v1-sectors") { | ||
extensions := map[miner.SectorLocation]map[abi.ChainEpoch][]uint64{} | ||
// are given durations within a week? | ||
closeEnough := func(a, b abi.ChainEpoch) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe make this an option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, document.
cmd/lotus-storage-miner/sectors.go
Outdated
} | ||
|
||
for _, si := range sis { | ||
if si.SealProof < abi.RegisteredSealProof_StackedDrg2KiBV1_1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe invert and use a continue?
cmd/lotus-storage-miner/sectors.go
Outdated
for _, si := range sis { | ||
if si.SealProof < abi.RegisteredSealProof_StackedDrg2KiBV1_1 { | ||
|
||
ml := builtin3.SealProofPoliciesV11[si.SealProof].SectorMaxLifetime |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move this into chain/actors/policy
and make it a function over the version.
cmd/lotus-storage-miner/sectors.go
Outdated
} | ||
|
||
newExp := ml - (miner3.WPoStProvingPeriod * 2) + si.Activation | ||
p, err := api.StateSectorPartition(ctx, maddr, si.SectorNumber, types.EmptyTSK) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really inefficient (searches all partitions/deadlines). OK for a first pass, but this could be very slow for some miners.
On the other hand, may be not... let's wait and see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I tried it for the largest miners, and it is...not fast. Easy optimization is to only load the actor state once, but that is not gonna be the critical path. Alternative is to iterate over deadlines, and pre-compute one very large map of sectors -> locations, and then hit that up as needed.
This is a "needs to be run once" command, though, so eh?
cmd/lotus-storage-miner/sectors.go
Outdated
for l, exts := range extensions { | ||
for newExp, numbers := range exts { | ||
scount += len(numbers) | ||
if scount > miner.AddressedSectorsMax || len(p.Extensions) == miner3.DeclarationsMax { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: abstract over policy.
cmd/lotus-storage-miner/sectors.go
Outdated
} | ||
p := &miner3.ExtendSectorExpirationParams{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why by reference? We're dereferencing everywhere.
} | ||
|
||
p := &miner3.ExtendSectorExpirationParams{} | ||
for l, numbers := range sectors { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we dedup this with the above loop? It's doing the exact same thing (except now we aren't sending multiple messages).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but eh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh == we aren't sending multiple messages here so it'll fail in some cases (although I guess we can say that that's pretty unlikely).
ced47ca
to
2855ec2
Compare
2855ec2
to
72c410c
Compare
} | ||
|
||
p := &miner3.ExtendSectorExpirationParams{} | ||
for l, numbers := range sectors { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh == we aren't sending multiple messages here so it'll fail in some cases (although I guess we can say that that's pretty unlikely).
Run
lotus-miner sectors extend --v1-sectors
.The
tolerance
flag can be passed to indicate what durations aren't "worth" extending. It defaults to one week, which means that sectors whose current lifetime's are within one week of the maximum possible lifetime will not be extended.The
expiration-cutoff
flag can be passed to skip sectors whose expiration is past a certain point from the current head. It defaults to infinity (no cutoff), but if, say,28800
was specified, then only sectors expiring in the next 10 days would be extended (2880 epochs in 1 day).Tested manually on butterfly (kinda)
Should be tested on a large mainnet miner