Back

@Aqraf あれ，結局ログなりなんなり見なかったんですか

@orumin journalctl でいろいろオプション付けて見たんですが、カーネルが怒ってるような文が見つけられなかったんです

@Aqraf なるほど。ちなみに fsck の repair しないオプションなら何か言ってたはずですが，何か出てませんでしたか。

@Aqraf fsck のオプションは file system によって違うのでどの fs かわからないとそれに対しては答えられないかな……。

@orumin ext4 を使っていました (いまも使ってる)
fsck 使う時に ext4 だぞってオプション渡してあげたほうがよかったんでしょうか……？

@Aqraf fsck は filesystem によって fsck.<fs name> を呼出すようになっててそこで切り替えてる。で，fsck.ext4 は e2fsck への symlink になっています。で，e2fsck は -p を付けないと repair しない。

@orumin fsck が実際に復旧やってくれるんじゃないんですね……なるほどです。
たしかに fsck -f したときに fsck じゃないプログラムのバージョン情報が1行出力されていたような気がします。

@Aqraf RAID の話題の流れで https://mstdn.maud.io/@orumin/101999104206014930 と toot したんですがこれ今回の件でも似た話なので。ここに toot したとおり fsck はあくまで filesystem というソフトウェアからみて異常系だったのを正常系にするだけです。

@orumin データとファイルシステムの両方を救ってくれるような思いでいたんですけど、そこまでは出来ないんですね。
ファイルシステムのことあんまり考えずに運用してきましたが、他のものも気になってきました……。

@Aqraf はい。そんなことはないので fs は異常系を検知するとまず read-only になってそれ以上の破損を防ぎ，かつユーザーに対処を促します。ユーザーは fsck のまえに dd などで一旦イメージダンプするなどその時点でとれるバックアップをした上で，壊れる前提で fsck で check したあと，場合によっては repair をします。で，普段の backup から file を戻したり，それでも帰ってこない file を最後に dd した image から気合で救出したりします。
ちなみに fsck ですらメタデータがイカれたままの fs はどうしようもないので mkfs で format するとキレイなメタデータになるので，そうするしかないですね。
（これらは storage が物理破損してない前提の話ですが

@orumin 普段からのバックアップと気合が必要なのですね……なるほどです。
今回は半年くらい起動していたんですが、異常系と判断し Read-only になるタイミングってどこなんでしょうか？
今回は再起動で立ち上がるところでしたが、起動してしばらく経ったある日突然……みたいなことがあると怖いなと思って。

@Aqraf 物理的に読めないのを検知したときですかねぇ。まあそのためにも普通は smartd なんかで S.M.A.R.T. 監視してアラート飛ばせるようにするですがそれで完璧にエラーを豫期できれば世の中の悲しい事故は全て消えるわけで，実際は本当に読めなくなるまでとくにアラート出ない壊れかたもありますし，常日頃自体に備えたバックアップするしかないですね。

@Aqraf ほかにも read-only になるタイミングとかあるかもしれませんが近年の Linux の filesystem のコードをそこまで読んでないので確かなことは言えなくてごめんなさい。まあ基本は起動時だと思いますね。dirty bit とかみて。

@Aqraf いえいえ。