alixのバックアップ用に使ってきたELECOM製のMF-AU2 USBフラッシュメモリが壊れてしまいました。 とはいっても読み出しについてはエラーは出ていません。
ちょっと普通じゃない使い方
このフラッシュメモリはext3フォーマットをした上で、DNSサーバにしているalixのバックアップ領域として使っていました。
バックアップ自体はpdumpfsで行なうためハードリンクが使いたかったので、ext3にしていたわけです。
alix+debianの組み合せだと、起動時にUSBメモリが認識されるタイミングが一定ではなく、使いたい時にマウントしたかったのがautofsにした理由です。
ちなみに設定ファイルは次のようにしていました。
/misc /etc/auto.misc
bk -fstype=ext3,noatime :/dev/disk/by-uuid/d83cc93b-a40e-4435-8de6-d18a56491f66
今回の症状
たまたまログインしてバックアップの様子を確認した時に発見しました。 家にもちゃんとnagios辺りで監視系を作らないとだめかなぁ。
新しくディレクトリを作ろうとすると次のようなメッセージが表示されます。
$ sudo mkdir test
mkdir: ディレクトリ `test' を作成できません: No space left on device
とはいえ、領域を全部使い切ったわけでもなく、まだ半分程度は余っています。
/dev/sdh1 3886448 1787812 1901212 49% /media/disk
常に100%を使い切るような使い方をすれば、あっという間に使えなくなる事は想像できたのですが、まだ51%残っている状態で、簡単に使えなくなり少し驚いています。
別の格安フラッシュメモリをチェックしてみる
念のため昨年末に近くの家電屋さんで放出されていたKingston製の格安メモリもチェックしてみると、みごとに不具合が出ていました。 ログの日付をみると2009/12/24のクリスマス前後から使い出したばかりみたいなんだけどなぁ…。
$ ls /misc/bk
ls: cannot access /misc/bk/2009: Input/output error
2009 2010 OLD do_pdumpfs.sh ignore.list latest lost+found stderr.log stdout.log
この状態だと2009ディレクトリ以下のファイル、ディレクトリにはアクセスできません。 まぁこっちはまだ書き込めているので、しばらくは使い続けてダメになってから交換しようと思います。
復旧までのステップ
この領域はバックアップ領域なので、簡単に復旧できるのが良いところです。
- 新しいUSBメモリを装着
- ext3フォーマット
- tune2fsでUUIDを調べて、/etc/auto.miscを書き換え
- do_pdumpfs.shスクリプトを配置する
あとはcrontabから/misc/bk/do_pdumpfs.shが自動的に呼ばれて終りです。 autofsをベースにしたpdumpfsとcrontabの組み合せはとてもお手軽で助かっています。
問題は稼働状況の把握だけですね。
さいごに
まぁバックアップ領域なので、また適当なフラッシュメモリを買ってくるつもりです。NANDメモリの製造元でもあるSANDISK製のものは価格のわりに速度も品質も安定していて好きだったんですけどね。最近はもう売られていません。
SONY製のハイスピードタイプは読み出しは早いですけれど、全体的なパフォーマンスは価格ほどではないですし、どれもこれも信頼性という意味ではイマイチな感じなんですよね。
とはいえ「今のところ」信頼している製品でもNAND MLCである限りは潜在的に問題があるのは間違いありません。 繰り返しになりますが、USBフラッシュメモリをext3フォーマットして使うことに問題があると思います。今回のように純増していく用途であれば、NILFSが最適でしょうね。でもNILFSはハードリンクに対応しているのかなぁ、今度試してみましょう。
ちゃんと使いたいならお金を出して10万回以上の書き込み/消去サイクルを保証しているTranscendのJetFlash 1xxシリーズを使うべきです。 仕事で使うなら、このクラスの製品がお勧めです。
0 件のコメント:
コメントを投稿