八方ふさがりになってきたので、一旦ここまでの経緯をまとめておこう。
少し前に、使っていた NAS が壊れた。
壊れる前の話も書かないといけないね。
NAS のデータは重要なので、定期バックアップを取るようにしていた。
バックアップ終了時には、管理者（僕）にメールが届く。
ふと気づくと最近バックアップしてない。
最後のバックアップは1か月前だった。
調子が悪いのかな、と思ってリブートしたら、起動しなかった。
これが故障の経緯。
新たな NAS は購入し、バックアップデータを書き戻した。
しかし、この1か月の間に作ったデータが、古い NAS に残っている。
このデータを救出したい。
旧 NAS の機種は、I/O データの landisk HDL2-G2.0。
2008年発売で、1.0T のディスクを2基搭載している。これを raid1 設定で使用していた。
raid1 で、それまで動いていたのだから、ディスクの損傷はないと思う。
再起動できないのだから、ハードウェアに問題がある可能性もある。
しかし、まずはディスクを取り出す。
2台はミラーされた同じもの、と考え、1台は保存。迂闊に手を付けて壊れても困る。
もう1台は、Linux マシンに接続してみる。
landisk に限らず、最近の安い NAS は中身が Linux で、ソフトウェアで raid を実現している。
ディスクには６つのパーテションがあった。
1. boot パーテション
2. root パーテション
3. swap パーテション
4. 拡張 パーテション
ここら辺は、非常に一般的な Linux のパーテションの切り方だ。
ちなみに、boot も root も、この後書く５番目のパーテションも ext3 。
2008年だと考えれば、これも標準的。
4の拡張パーテションの中には、２つの論理パーテションが入っていた。
5. log などが入っている。おそらく /var にマウントするもの
6. 最大の容量を割り振られた、おそらくデータパーテション
6 をマウントして覗いても、中身は空っぽだった。
おや、おかしい。やっぱりレイドが壊れて、データは消失、再構築されてしまったのか。
…とおもったが、df で良く見ると、およそ 1T の容量のうち、半分程度が使われている。
NAS にはデータが 500M くらい入っていた。やっぱりこれがデータ領域だ。
ファイルタイプは xfs 。
今では各種ディストリビューションの標準ファイルシステムとなりつつあるが、僕はそれほど詳しくない。
知っていることとしては、大容量データを扱うためのジャーナルファイルシステムとして新たに設計されたもので、つぎはぎだらけの ext4 なんかよりも「素性が良い」という程度だ。
でも、もちろん ext4 なんかと互換性が無い。
残念ながら僕は互換性のためにまだ ext4 を使っていて、xfs は馴染みがない。
しかしまぁ、大容量も扱えるしジャーナルだし、なにより 2008 年当時には ext4 は信頼性がなかった。
xfs を使っているのは、ある意味当然だろう。
容量は使われているのでファイルは残っていると思われる。
しかし見えないのはなんでだろう。ファイルを見せないようにロックする方法とかあるんだろうか。
ここで xfs のことを調べ、実装方法にミスがあったことを知る。
古い xfs では、ジャーナルの記録が CPU のエンディアンの影響を受けていたそうだ。
「そうならないように設計していたはずなのに、実装ミスだった」とのこと。つまりはバグだ。
現在の xfs では修正されているらしい。
違うアーキテクチャの CPU でマウントする際には、元マシンで xfs_repair してから、新たなマシンでマウントすること。
xfs_repair では、ジャーナル情報を元にファイルシステムの整合性を調べ、チェックが終わったジャーナルは破棄される。
バグがあったのはジャーナル部分だけなので、これで違う CPU でも開けるらしい。
ジャーナルだけが問題なら、ファイル名とかは見えてもいいんじゃないかな、と思うけど、どうも詳細不明。
ともかく、ファイルが見えないことは事実だし、「元マシン」で xfs_repair することも叶わない。
探すと、x86 の Linux で、エンディアンが違う xfs を開くためのパッチ、とかもあるようだ。
しかし、これらは xfs のソースプログラムにパッチを当てるもので、カーネル再構築からやらなくてはならない。
家の Linux マシンは仕事に使っている物なので、自分でカーネル再構築して不安定になると困る。
この方法は見送り。
＃後日追記(2015.2.2)
この節に書いてあること、かなり間違ってました。
「ジャーナル部分にバグがあったらしい」と言っている人がいたのは事実だけど、実際にはエンディアンは「当初は気にしていなかった」というのが事実のようだ。
SGI のマシンから Linux に、まずは動くように移植され、ついでエンディアンの違いを無くすように、非常に多くのパッチが当てられ続ける。
XFS Endian bug Fix と書かれた投稿を探しただけでも、2006年ごろから 2012年ごろまで、非常にたくさんあった。
なので、元マシンで xfs_repair すればよい、という情報自体が誤り。
x86 の Linux でエンディアンが違う xfs を開くためのパッチ、ということを書いてしまったが、これも誤りで、僕がバグ Fix パッチを勘違いしただけ。
xfs_repair すると、/lost+found の中に、読めなくなったファイルが復活する、と書かれている記事もあった。
ただし、ファイル名は数字の羅列になってしまう。
これ、i-node 番号をファイル名にして、アクセスできなくなったファイルを復活させるものです。
（i-node とは、UNIX 伝統のファイル保存方法で、ファイルの実態を表す構造。
UNIX では、ファイルとファイル名は別物で、ファイルはあるのにファイル名が見当たらない、という状況にシステムが気付くと、/lost+found ディレクトリに移動される。）
ただ、先に書いたバグの中には、ファイルのデータ格納に関わるものもある。
このバグが LANDISK に残っているとすれば、「大きなファイルの場合、先頭は残ったとしても、末尾までは保証されない」と思うので、あまりお勧めできない。
データパーテションには手を出せないが、システムパーテションなどは見ることができる。
/etc/samba/smb.conf が 0byte だ。
起動しない原因はこれか？ と思ったけど、情報を調べると、landisk では毎回起動時に smb.conf を自動生成するようだ。
NAS にとって重要なファイルだから、うっかり破損したりしないようにそういう仕組みにしてあるらしい。
ファイル日付を見ると壊れた頃なので、何らかの原因で生成できなかったのかもしれない。
なぜ 0byte になったのかは不明。
自動生成しているらしいが、探してみてもどこで作りだしているのか不明。
うーん、とりあえず、ダメもとで設定ファイルを作ってみようか。
この時、disk full と怒られた。
え、なんで？ いくら root 領域だからって、そんなにギリギリに作ってあるわけがない。
しかし、本当に容量が使い切られている。
/var/log ディレクトリでもあふれたのかな、と思っても、そのディレクトリは無い。
ログ関係は５番目の領域に入っていたし、ちゃんとローテートされていたので問題ないのだろう。
du -s * してみる。
これで、ディレクトリごとにどの程度の容量を使っているかがわかる。
/bin なんかが大きいのは当然として、/usr が不自然に大きい。
追いかけると、/usr/share/usb2 というディレクトリがあり、この下が異常に大きかった。
そして、そこにはデータ領域のコピーがあった。（もちろんほんの一部）
どうやらこれが故障の原因。
このディレクトリは、背面 usb ポートに接続したディスクがマウントされる、マウントポイントのようだ。
定期バックアップのために接続していたディスクが、なぜかアンマウントされたのだろう。
ただし、アンマウントしてあるとはいえ、デバイスとしては接続はされている。
landisk は、デバイスがあるからバックアップを取ろうとして、データ領域の内容を /var/share/usb2 に書き込む。
しかし、そこはデバイスがなく、root ディスクのディレクトリに書き込まれただけだ。
ディスクのほぼすべてを占める領域からのコピーに、当然 root 領域はパンク、disk full になった。
そして、ディスクにデータを書き込めることを前提にしてあるソフトは多い。
これらがすべてうまく動かなくなる。
その一つが、おそらく smb.conf を作り出すためのプログラムで、データを作り出せないまま 0byte にしてしまったのだろう。
再起動に失敗するわけだ。
/var/share/usb2 の中を削除し、ディスクを NAS に戻して起動してみる。
…残念ながら動かない。
もう一度 Linux に接続して中身を見る。
/.autofsck を見つけた。
このファイル、Linux 起動時にファイルシステムのチェック(fsck)を行うためのものだ。
もしかして再起動しない原因はこれか？
再起動しないのではなく、fsck に時間がかかっているだけかもしれない。
＃fsck は非常に遅い。
/.autofsck は、起動後に自動的に作られる。そして、終了時に自動的に消される。
もし正常終了しないと、残されたままになり、次回起動時に fsck が動く。
つまり、なにか異常な状態で終了したので、ファイルシステムを念のためチェックした方がいいよ、ということ。
たしか、最後の再起動時に、いつまで待っても終了しなかったので電源を抜かざるを得なかった。
だから残っているのだろう。
/.autofsck を消したディスクを NAS に戻し、起動してみる。
…だめだ。やっぱり起動できない。
fstab の第6パラメータを 0 にしてみたり、/fastboot を作ってみたり。
（いずれも、fsck をさせないための設定）
しかし、やっぱりうまくいかない。fsck が問題ではないのか。
ふときづいて、NAS から取り出したディスクのパーテションを tune2fs -l してみる。
この中に、「最後にマウントされた日付」がある。
…NAS 上では、どのパーテションもマウントされていない。
PC が起動するときは、MBR （マスターブートレコード：ディスクの第１セクタのこと）からプログラムを読み込み、実行する。
複雑なのでざっくり書くと、このプログラムが第２のプログラムを読み込んで実行し、そのプログラムがさらに OS を読み込む。
Linux の場合、boot パーテションに OS のファイルが入っている。
boot パーテションだけ分けておくのは歴史的経緯もあるが、初期の「OS 読み込みプログラム」が、HDD の冒頭付近のsectorしか読めなかったためだ。
だから、boot パーテションの OS はマウントせずに読み込まれる。
そして、OS が起動すると、root パーテションをマウントする。
root パーテションには起動に必要な設定も、必要なプログラムも入っている。これで無事に起動が出来る。
起動中に、boot パーテションもマウントされ、/boot の下に接木される。
「最後にマウントされた日付」がどうなっているのかわからないのだが、起動時に自動的にルートになるのは含まないかもしれない。
しかし、少なくとも /boot に接木する段階にまでは至っていないことがわかる。
さて、どこで止まっているのか。
なにぶん、動作が全く外から見えないので調べようがない。
landisk には、前面に３つのランプがついている。
１つは電源ランプ。あとの２つは、２台のディスクの状態を示すランプ。
ディスクの状態は、いわゆる「アクセスランプ」ではなくて、異常を伝えるための物。
普段は消灯しているけど、ディスクが動かなかったりすると赤く点灯する。
電源ランプは、通常は点灯。起動時・終了時・なんらかのお知らせがあるときなどは点滅する。
landisk が外に情報を出す手段はこれしかない。
じゃぁ、これを使ってみよう。
ここまでに、起動時に動く各種スクリプトを見ているが、どこかに制御しているらしいプログラムがあった。
…見つけた。/usr/local/bin/ledcont だ。
中を見ると perl スクリプトだった。
I/O ポートを直接叩き、LED コントローラに指示を渡しているようだ。
次に inittab を読む。
UNIX では、OS が起動するとまず init というプログラムが呼び出される。
init は inittab に従って次々とプログラムを起動し、ユーザーが利用できる状況を整える。
ただ、inittab の書き方は、UNIX でも会社によって違うし、Linux でもディストリビューションで違う。
ここまでに気づいていたが、landisk は debian だ。僕が普段使っているのは redhat 系なので、少し違う。
（ちなみに、僕は slackware 系を使っていた時代もあるので、そちらならなんとか。
Netwalker は ubuntu で debian 系なのだけど、システムハックするほど使い込んでない）
ふむ、一番最初に読み込まれるスクリプトは、/etc/init.d/rcS のようだ。
このスクリプトは、 /etc/rcS.d/ 以下のスクリプトを次々起動するための物。
そこで、rcS の冒頭で ledcont を使い、表示を「起動中」以外にしてみることにした。
これで起動してみると…
LED の表示が変わらない。ということは、inittab すら読み込まれていないのか…
というわけで、現状お手上げ状態に。
最初のプログラムすら起動しない状況って、やっぱり本体が壊れている可能性もある。
ちなみに、情報によれば MBR は 0 しか書かれていない、らしい。
一般的なパソコン向けではないので、システムの ROM にブートシーケンスを入れてあるのだろう。
だから、MBR が壊れたわけではない、と思う。
OS の起動イメージが壊れている可能性はある。
実は、boot 領域には、工場出荷時の各パーテションのイメージが、tar+gz 圧縮で入っている。
この中の起動イメージと比べてみたら違っていた。
これは、アップデートがあったので当然。
最新版のアップデートは昨年暮れに出ていて、このファイルをダウンロードしてあったが、アップデートにはなぜか失敗していた。
（ダウンロードは boot 領域内に行われ、アップデートは root 領域に行われる。
先に書いたように、root が disk full だったので失敗したようだ）
このアップデートファイル内にも OS 起動イメージがあった。
昨年末のアップデートでは起動イメージは変わらなかったようで、日付が手元の物と同じ。
diff したら、全く同じ。
つまり、起動イメージに問題は無さそう。
電源ランプは、電源を入れてから
・起動中の点滅
・一瞬だけ点灯
・再び点滅
という動きをする。
点灯するところで何か動きがあるわけだけど、最初の点灯で起動イメージを読み込んで、読み込み終わったところで「起動中」の点滅を終了、その後起動イメージを動かすと、そのプログラム内で再び点滅を始めるのではないか、と思っている。
（思っているだけで根拠はない）
このあと、なぜか root ファイルシステムのマウントに失敗し、そのため init も動き出さないのだろうな。
今後の動き。
まずは、データの保全が大事。
方針は２つあって、Raise Data Recovery for XFS というシェアウェアを使うのが一つ。
これは、Windows 上で動くソフトで、壊れた XFS からでもかなり高確率でデータを復元してくれるらしい。
landisk で使っていたディスクからでも取り出せた、というのだから、先に書いたエンディアンの違い問題も対処済みなのだろう。
シェアウェアなのだけど、21.95ユーロ＝3000円程度。
フリーウェアの似たソフトの場合、復旧率が悪いというので多少の出費はやむ得ないところ。
もうひとつは、新しい NAS の外付けドライブとして無理やり突っ込んでみる方法。
新しい NAS も ARM を使っているので、エンディアンの違い問題は出ない…可能性もある。
そもそも読めない可能性だってあるし、XFS の外付けが読めたとしても、「エンディアン問題対処済み」の新たなプログラムを使っていたら、やっぱり古いバグありデータは読めないかもしれない。
さらに、SATA ディスクを USB 接続するなり、eSATA 接続するなりするためのアダプタを購入する必要もある。
…多分、先のシェアウェア代金より高くつく。
というわけで、方針はだいたい決まっているようなもの。
データ保全できれば、先に書いた「工場出荷状態への復旧」のためのファイルを試してみるのもよい。
これを行うと、多分データは消えるけど、NAS が復活するかもしれない。
同じテーマの日記(最近の一覧)
関連ページ
ビッグエンディアンとスモールエンディアン(1980)【日記 15/04/01】
ビッグエンディアンとリトルエンディアン(1980)【日記 15/04/01】
デイビッド・パターソン 誕生日(1947)【日記 15/11/16】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |