Case study: recovery of a corrupted 12 TB multi-device pool
salt4034
29 points
3 comments
April 06, 2026
Related Discussions
Found 5 related stories in 84.3ms across 8,303 title embeddings via pgvector HNSW
- My first in-prod corrupted hard drive problem r1chk1t · 41 pts · May 08, 2026 · 50% similar
- Recovering files from beyond the grave using PhotoRec speckx · 60 pts · April 30, 2026 · 48% similar
- Copy Fail: 732 Bytes to Root on Every Major Linux Distributions fratellobigio · 15 pts · April 29, 2026 · 43% similar
- Copy Fail: 732 Bytes to Root on Every Major Linux Distribution eyalitki · 15 pts · April 30, 2026 · 42% similar
- Copy-fail-destroyer: K8s remediation for CVE-2026-31431 evenh · 17 pts · April 30, 2026 · 42% similar
Discussion Highlights (3 comments)
phoronixrly
To theal author: did you continue using btrfs after this ordeal? An FS that will not eat (all) your data upon a hard powercycle only at the cost of 14 custom C tools is a hard pass from me no matter how many distros try to push it down my throat as 'production-ready'... Also, impressive work!
stinkbeetle
> Case study: recovery of a severely corrupted 12 TB multi-device pool, plus constructive gap analysis and reference tool set #1107 Please don't be btrfs please don't be btrfs please don't be btrfs...
yjftsjthsd-h
> This is not a bug report. [...] The goal is constructive, not a complaint. Er, I appreciate trying to be constructive, but in what possible situation is it not a bug that a power cycle can lose the pool? And if it's not technically a "bug" because BTRFS officially specifies that it can fail like that, why is that not in big bold text at the start of any docs on it? 'Cuz that's kind of a big deal for users to know. EDIT: From the longer write-up: > Initial damage. A hard power cycle interrupted a commit at generation 18958 to 18959. Both DUP copies of several metadata blocks were written with inconsistent parent and child generations. Did the author disable safety mechanisms for that to happen? I'm coming from being more familiar with ZFS, but I would have expected BTRFS to also use a CoW model where it wasn't possible to have multiple inconsistent metadata blocks in a way that didn't just revert you to the last fully-good commit. If it does that by default but there's a way to disable that protection in the name of improving performance, that would significantly change my view of this whole thing.