A hard power cycle corrupted a 12 TB Btrfs pool spanning three devices, leaving the extent tree and free space tree in a state that native repair tools couldn't resolve. The corruption caused btrfs check --repair to enter an infinite loop of 46,000+ commits, rotating backup root slots past any pre-crash recovery point. Recovery required custom C tools built against the internal btrfs-progs API.

Out of 4.59 TB of data, only 7.2 MB was lost during the recovery process. The author documented the incident in detail, proposing nine specific improvements to the Btrfs codebase that could prevent similar recovery scenarios. These include progress detection in repair operations, symmetric handling of delayed references, and new rescue subcommands for rebuilding extent trees and cleaning orphan inodes.

The complete recovery toolkit and single-line patch are available under GPL-2.0 at GitHub. While the author isn't proposing these as direct upstream patches, the analysis provides valuable insights for Btrfs developers working on filesystem resilience and repair mechanisms.