slack

• https://mongodb.slack.com/archives/C072LJP3EQ3/p1776695339572599
• https://mongodb.slack.com/archives/C02SQPJHQ85/p1776696909840279
   
   
   
  Potential hard blocker for single-shard disk write blocking.
  Context: * Mongotune disk write blocking command setUserWriteBlockMode ** relies on the reason field as a guardrail to avoid unblocking or getting unblocked by other processes that issue disk write blocking such as mongosync (https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior/)

• Sharded clusters do not respect this field (https://github.com/10gen/docs-mongodb-internal/blob/main/content/manual/upcoming/source/reference/command/setUserWriteBlockMode.txt#L32).

Impact: # Scenario: Mongosync clears a Mongotune DWB block

1. 1. Disk utilization is high.
   2. Mongotune blocks.
   3. Mongosync starts cluster migration and blocks.
   4. Mongosync completes cluster migration and unblocks.
   5. Node disk becomes overloaded and crashes (existing behavior).
2. Scenario: Mongotune clears a Mongosync block
   1. Mongosync starts cluster migration and blocks.
   2. Disk utilization is high.
   3. Mongotune blocks.
   4. Auto-scaling activates and disk size increases.
   5. Mongotune unblocks.
   6. The node may begin accepting writes that mongosync assumes are blocked, risking migration correctness (unexpected writes to the destination outside the supported cutover flow).

Questions: # Could this cause data corruption?

1. If this event were to occur is it recoverable?
2. Is this worth the availability improvement?
3. Can we mitigate these scenarios by documenting the risk of cluster migration if disk utilization is already high?