Whatever `btrfs` did, it did a proper job of it.
10 hours later and `btrfsck --repair` still grinding away. Yes I took a snapshot of the disk before making changes.
Still going… seeing a lot of messages like this:
```
ref mismatch on [35132342272 8192] extent item 1, found 0
data extent[35132342272, 8192] bytenr mimsmatch, extent item bytenr 35132342272 file item bytenr 0
data extent[35132342272, 8192] referencer count mismatch (root 256 owner 227508 offset 149012480) wanted 1 have 0
backpointer mismatch on [35132342272 8192]
owner ref check failed [35132342272 8192]
repair deleting extent record: key [35132342272,168,8192]
Repaired extent references for 35132342272
ref mismatch on [35132350464 8192] extent item 1, found 0
data extent[35132350464, 8192] bytenr mimsmatch, extent item bytenr 35132350464 file item bytenr 0
data extent[35132350464, 8192] referencer count mismatch (root 256 owner 227508 offset 149020672) wanted 1 have 0
backpointer mismatch on [35132350464 8192]
owner ref check failed [35132350464 8192]
repair deleting extent record: key [35132350464,168,8192]
Repaired extent references for 35132350464
```
As some might've guessed… that `fsck` is still grinding away.
24+ hours. I thought large EXT2 volumes took a long time to check, but it seems BTRFS can be just as bad.
```
ref mismatch on [77402689536 8192] extent item 1, found 0
data extent[77402689536, 8192] bytenr mimsmatch, extent item bytenr 77402689536 file item bytenr 0
data extent[77402689536, 8192] referencer count mismatch (root 256 owner 227855 offset 33595392) wanted 1 have 0
backpointer mismatch on [77402689536 8192]
owner ref check failed [77402689536 8192]
repair deleting extent record: key [77402689536,168,8192]
Repaired extent references for 77402689536
```
Not sure what number that's expected to climb to. Maybe with some luck I might be "back home" this afternoon, but at this rate, who knows?
Stuart Longland (VK4MSL)