Skip to content

Support only requiring 2/3 downstairs to activate#10677

Open
jmpesp wants to merge 1 commit into
oxidecomputer:mainfrom
jmpesp:support_2_out_of_3_activation
Open

Support only requiring 2/3 downstairs to activate#10677
jmpesp wants to merge 1 commit into
oxidecomputer:mainfrom
jmpesp:support_2_out_of_3_activation

Conversation

@jmpesp

@jmpesp jmpesp commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Historically Crucible required all three downstairs in order to activate, and this presents a challenge when one sled is offline: any upstairs with a downstairs on that sled would not be able to activate until that sled came back. However if Crucible had activated it could have tolerated one downstairs going away and coming back just fine.

Crucible can be changed to support only requiring 2/3 downstairs to activate (see RFD 542), and has been, but there's a region replacement related wrinkle to solve before shipping that: previously an Upstairs would only activate when all three downstairs were in sync, and in the case that a region replacement was done when there was no Upstairs (or the Upstairs was stopped) activation was taken as a signal that reconcilation had completed successfully. With the change that only 2/3 downstairs are required to be in sync this is no longer a reliable signal that the region set was in sync.

Richer Volume health status was added to expose more details and allow Nexus to determine if a reconcilation or repair was in progress - this is the signal that Nexus has to now use to consider a post region replacement reconcilation successful. Change to that, and remove some out-of-date comments.

Historically Crucible required all three downstairs in order to
activate, and this presents a challenge when one sled is offline: any
upstairs with a downstairs on that sled would not be able to activate
until that sled came back. However if Crucible had activated it _could_
have tolerated one downstairs going away and coming back just fine.

Crucible can be changed to support only requiring 2/3 downstairs to
activate (see RFD 542), and has been, but there's a region replacement
related wrinkle to solve before shipping that: previously an Upstairs
would only activate when all three downstairs were in sync, and in the
case that a region replacement was done when there was no Upstairs (or
the Upstairs was stopped) activation was taken as a signal that
reconcilation had completed successfully. With the change that only 2/3
downstairs are required to be in sync this is no longer a reliable
signal that the region set was in sync.

Richer Volume health status was added to expose more details and allow
Nexus to determine if a reconcilation or repair was in progress - this
is the signal that Nexus has to now use to consider a post region
replacement reconcilation successful. Change to that, and remove some
out-of-date comments.
@jmpesp jmpesp requested a review from leftwo June 25, 2026 23:42
@leftwo

leftwo commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Some notes came up during in office discussions with @jmpesp

For 2/3 activation, we have to be careful with region-replacement.
We can't allow 2/3 activation if one of the "good" downstairs is the region being replaced.

Consider this set of steps:

  • A write to block 1 goes out to all three downstairs.
  • Downstairs 1 goes offline.
  • Another write to block 1 goes out, this time just to downstairs 2, 3
  • Downstairs 2, 3 go offline.
  • Instance stops.
  • Downstairs 1 comes back online.
  • Downstairs 2 is expunged or otherwise determined to be bad and a replacement is issued.
  • Instance is started

We now have downstairs 1 and the replacement for downstairs 2 online.
If we allow 2/3 activation at this point, we will copy everything from downstairs 1 to the new downstairs replaced at 2.
This means the second write we did (and acked to the guest) will be lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants