@nonamea774 Btrfsではb-treeにキー(たとえばファイル名とか)に対応する値(たとえばそのファイルのデータ位置)が記録されてる。値のサイズは可変である。そのため、このキーに対応する値はここというオフセットと値のサイズが保存される。
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

@nonamea774 値はブロックの後ろから積めて配置される。ここで、あるキーkとその次のキーlを考える。lの値のオフセット+lのサイズ=kの値のオフセットという式が成り立つ。今回のエラーログはある一つのブロックについて、この式が成り立っていない場所があることを示唆している
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

@naota344 一つのブロックが壊れているだけ、ということですか？どのように回復可能でしょうか？
— 中野のな改ぽよ (@nonamea774) 2015, 5月 7

@nonamea774 一つのブロックのしかもオフセットなので周りから計算可能ということですね。てきとーにそのブロックのoffset直すCのプログラム書くと直るよ。btrfsckのコード見ながら書けばよい
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

@nonamea774 これの「さて、ここまでは」以降を参照のこと http://t.co/sAtyn9SIpa
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

@nonamea774 なお、近年のbtrfsckにはoffset fixのコードが入っているので、バックアップ後にbtrfsckするのもよい
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

@nonamea774 https://t.co/09vq4VS6ay を冒頭のmake ruleにしたがってmake (Makefile に追記すれば多分動くかな?)して ./oreorefsck 実行したら多分直る
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

とりあえずこれで治りました。

なにか

btrfs-debug-tree が SEGV した。
— 中野のな改ぽよ (@nonamea774) 2015, 5月 7

あーそっか stripped だからよくわからないな……。 pic.twitter.com/MLLQNuCxO9
— 中野のな改ぽよ (@nonamea774) 2015, 5月 7

@nonamea774 正しい値は16104(0x3eea)で書かれてる値は48874(0xbee4)ですね。一つbitが立ってる。そういうことです
— 倍増計画へのcontribution (@naota344) 2015, 5月 7

btrfs の slot offset が1bit立ってておかしくなる問題、自分のところでも何度か起きたことがあるが、なぜ起きてしまうのだろう https://t.co/yyw6wnyNx1
— 倍増計画へのcontribution (@naota344) 2015, 5月 8

これがおもしろいのは checksum (crc32c) は通っているところ。 crc32c は通るが1bit 確実にflipしてる
— 倍増計画へのcontribution (@naota344) 2015, 5月 8

Togetter でやれ

一理ある。

その他

HDD 治ったのはいいけれど、emerge 中に謎の ICE を踏む現象

が辛すぎる感じだ。 Gentoo はむずかしい。