悲劇は年度末にやって来た

RAID5 崩壊

2010年5月20日 記載、2011年10月編集


ここには、RAID5 + XFS の復旧と、
HDL-GT1.0 [LAN DISK Tera HDL-GT1] ファイル復旧が記載されています。

ドキュメントの充実さとメーリングリストに、ファイル復旧への糸口がありました。

XFSに関するFAQが解決の鍵をもたらした。
http://xfs.org/index.php/XFS_FAQ
http://xfs.org/index.php/XFS_FAQ#Q:_What_is_the_issue_with_directory_corruption_in_Linux_2.6.17.3F
Q: What is the issue with directory corruption in Linux 2.6.17?

及び、
http://docs.cray.com/books/S-2377-22/html-S-2377-22/fixed6bhdyq9i26.html
7.7.1. Common Error Messages

先人達の経験が綴られた、質問者の溜息が聞こえてきそうな文章、そして解決の糸口になる投稿。
それらが、こちらの問題解決につながった。
http://oss.sgi.com/archives/xfs/2007-01/msg00150.html


!! そこにデータがある限り諦めない !!

!! ドキュメントは読む !!

!! man は必ず目を通す !!
「英語が分からない」は読まない理由にならない。なぜなら翻訳サイトが いっぱいある からです。
読まない事によって、知らずにいることが多くなり、また失うものがあるかもしれない。


もう一つ、
!! エラーは必ず読み込む !!
エラー表示には、糸口が沢山ある。


2010年4月1日、2日、元職場の仲間から電話連絡
RAIDを組んでいた文書サーバー、HDL-GT1.0 [LAN DISK Tera HDL-GT1]が、「RAID崩壊」と表示してアクセスできない。
通常青色のランプが赤色で派手に光り、ビープ音が鳴りつづける。


4月2日、メール連絡
使用していたサーバーの機種名と型番、ディスク構成(何台組みになっているか等)を問い合わせる。
機種名　I-O DATA HDL-GT1.0
型番　　XGH0050023Q7
ディスク構成は 4台組


4月3日、花見
4月4日、出張


4月5日、HDL-GT1.0、作業ディスク、作業PC預り。メール連絡
13時、各機器預り。状況聞き取り
作業内容：
HDL分解 → UARTコネクタ確認
複製用ディスクの用意 → USB外付けディスク4個分解
RAIDディスク1 → HDD-1 複製、250GBの複製に約３時間
3507.5kの読み込みエラー
dd_rescue: (warning): /dev/XXX (70237775.5k): Input/output error!
23時終了


4月6日、HDL-GT1.0動作確認、機能を試す。
HDL-GT1.0は非常時にまったく使いものにならない。製品として非常時対応がなっていない。
再構成に6時間かかる。
作業内容;
HDL-GT1.0単体の作業では、復旧できない。
telnetdを起動させるためのスクリプトを挿入する。
再度、4ディスクの複製作業
シリアル経由での操作を考え、作業PC拝借のメール連絡
telnetd起動が出来ない場合を確認
25時終了


4月7日、設定、ログファイルなどを読む。
設定ファイルなどを読む mount /dev/sda{1,2} /mnt/XXX
logを読む mount /dev/sda{4,5} /mnt/XXX
一ヶ月まえから不具合の表示がある。
26時終了


4月8日、Knoppix機にSATAを4台つなげての作業を以降は行う。
SATAケーブル購入。RAID再構成を行う。

root@Microknoppix:# modprobe md_mod
root@Microknoppix:# mknod /dev/md10 b 9 10
root@Microknoppix:# mdadm -A /dev/md10 /dev/sd[abcd]6
これでは、再構成が行われなかった。

# mdadm -A -R -f -v -U resync /dev/md10 /dev/sd[abcd]6

-A, --assemble
    以前存在していたアレイを編成する。

-R, --run
    アレイを構成するドライブの数が必要数に満たなくてもアレイを起動させる。
    通常ドライブの数が足りない場合で --scan が指定されない場合はアレイは編成されても起動はしない。
    このオプションにより、とにかく起動させようとする。

-f, --force
    スーパブロックが古くてもアレイの作成を行う。

-U, --update=
    アレイ編成時、各デバイスのスーパブロックを更新する。
    有効な引数は sparc2.2，summaries，super-minor resync のいずれかである。

    summaries オプションはアレイのスーパブロック内のサマリ情報を訂正する。
    サマリ情報とはそのアレイを構成するデバイスの状況を示すもので、
    トータル，稼動中，アクティブ，不良，スペアの各個数のことである。

    super-minor オプションは各デバイスのスーパブロックのマイナー番号を、
    編成されるアレイのマイナー番号に変更する。
    カーネル 2.6 以上ではこれが自動的に行われるため、このオプションを指定する必要は無い。

    sparc2.2 オプションは RAID パッチが施された Linux 2.2 を Sparc
    マシンで走らせて作成されたアレイのスーパブロックを補正する。
    このカーネルで作られたアレイのスーパブロックにはアライメントの問題があることがわかっている。
    --examine --sparc2.2 とすることでこの問題の有無を調べることができる。

   The resync option will cause the array to be marked dirty meaning that
    any redundancy in the array (e.g. parity for raid5, copies for raid1)
    may be incorrect. This will cause the raid system to perform a "resync"
    pass to make sure that all redundant information is correct.

# mdadm -A -R -f -v -U resync /dev/md10 /dev/sd[abcd]6
mdadm: looking for devices for /dev/md10
mdadm: /dev/sda6 is identified as a member of /dev/md10, slot 0.
mdadm: /dev/sdb6 is identified as a member of /dev/md10, slot 1.
mdadm: /dev/sdc6 is identified as a member of /dev/md10, slot 2.
mdadm: /dev/sdd6 is identified as a member of /dev/md10, slot 4.
mdadm: added /dev/sdb6 to /dev/md10 as 1
mdadm: added /dev/sdc6 to /dev/md10 as 2
mdadm: no uptodate device for slot 3 of /dev/md10
mdadm: added /dev/sdd6 to /dev/md10 as 4
mdadm: added /dev/sda6 to /dev/md10 as 0
mdadm: /dev/md10 has been started with 3 drives (out of 4) and 1 spare.
root@Microknoppix:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md10 : active raid5 sda6[0] sdd6[4] sdc6[2] sdb6[1]
      725768256 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
      [>....................]  recovery =  0.1% (421376/241922752) finish=38.2min speed=105344K/sec

# mount /dev/md10 /mnt/data
だが、中身が見えない。ん〜。

この4月8日時点で、ファイルシステムを確認すれば、その後に、
XFSファイルシス テムの xfs_repairを行い、xfs_db にてcore.modeを修正を行えたらば、早期の復旧ができただろう。
花見もその結果と合わせて、充分に楽しめただろうと思う。

4月9日、各ディスクの時刻のずれを確認
No MD を疑い、各ディスクにzapを行うことを考える。
ディスク4台ではなく、3台(/dev/sd[abc]6)での縮退モードのRAIDの構成を考える。

4月10日、休み

4月11日、raidzap.cのコンパイル
raidzap を用いてzapを行う。
各ディスクは正常を確認
 Yes MD
 version      = 0.90.0
 uuid         = cd5e6001-cde20fc4-ea938443-ab7344b1
 event_lo     = 0
 event_hi     = 1144940
 level        = 5
 nr_disks     = 4
 active_disks = 3
 spare_disks  = 1
 failed_disks = 1
 chunk_size   = 65536
 state        = errors
 this state   = 6SA
 disk number  = 0
   no        = 0
   dev       = 8,6
   raid_disk = 0
   state     = 6SA
      no        = 0
      dev       = 8,6
      raid_disk = 0
      state     = 6SA
      no        = 1
      dev       = 8,22
      raid_disk = 1
      state     = 6SA
      no        = 2
      dev       = 8,38
      raid_disk = 2
      state     = 6SA
      no        = 3
      dev       = 0,0
      raid_disk = 3
      state     = 9FR


4月12日、fsck をかける
RAIDの再構成後にfsckを行うがディレクトリは見られず。

4月13日、花見

4月14日、作業PCを追加要請
fsck -y /dev/md10
lost+found に数字のファイル名、拡張子無し


4月15日、作業PCを2台にする。午前中にPCを受け取り。
ファイルシステムを確認
df -T
！！！ファイルシステムは、XFSであることに、今更、気づく！！！

ファイルシステムの修復にはfsck ではなく、xfs_repairであることに気づく。
( fsck.xfs -> xfs_repair )

Knoppixはエラー無くmountしていたので、ファイルシステムの確認を忘れていたのである。

あ〜〜。。。
ファイルシステムを確認しなかったのは、なんたる不覚
基本の操作を怠ったので、一週間が過ぎてしまった。
早期の復旧と花見の為にも、確認作業、基本操作は怠ってはならないと、反省しました。


root@Knoppix:~# df -T -h
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/hda   iso9660    667M  667M     0 100% /cdrom
/dev/md10      xfs    693G  251G  442G  37% /ramdisk/home/knoppix/data
↑
XFSですね。

root@Knoppix:~# xfs_info /dev/md10
meta-data=/dev/md10              isize=256    agcount=32, agsize=5670064 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=181442048,
imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=32768, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

root@xfs_repair -P  /dev/md10
found candidate secondary superblock...
error reading superblock 11 -- seek to offset 255470403584 failed
unable to verify superblock, continuing...

xfs_repair は途中で止まる。


4月16日、休み


4月17日、xfs_repair xfs_ncheck
xfs_repair を行うが、segment fault.
Phase 1 - find and verify superblock...
Phase 2 - zero log...
        - scan file system freespace and inode maps...
size of entry #0 overflows space left in in shortform dir 403036996
junking 255 entries
corrected directory 403036996 size, was 8, now 6
size of last entry overflows space left in in shortform dir 403036997,
resetting to 23
entry contains illegal character in shortform dir 403036997
junking entry "" in directory inode 403036997
corrected directory 403036997 size, was 2, now 6
directory 403036997 offsets too high
corrected entry offsets in directory 403036997
entry "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" in
shortform directory 403036999 references invalid inode 98257346
entry contains illegal character in shortform dir 403036999
junking entry "" in directory inode 403036999
entry "size of last entry overflows space left in in shortform dir
403036999, resetting to -1
segment fault.
 エラー表示で処理が止まる。

xfs_ncheckにて、i-nodeフォルダ名と日本語が表示される。
xfs_各コマンドを調べる。


4月18日、作業なし


4月19日、竹の子掘り
xfs_db と xfs_repair で修復完了

segment fault.
 エラー表示で処理が止まる。
調べよう。。。

http://docs.cray.com/books/S-2377-22/html-S-2377-22/fixed6bhdyq9i26.html
7.7.1. Common Error Messages

entry references free inode 2444940 in shortform directory 2444922 junking entry “fb” in directory inode 2444922

 A directory entry points to an inode that xfs_repair has determined is actually free.
 xfs_repair junks the directory entry. The term shortform means a small directory.
 In larger directories, the entry deletion is usually a two-pass process. In this case,
 the second part of the message reads something like marking bad entry, marking entry to be deleted, or will clear entry.

一つの i-node よりも他のディレクトリ、ファイルを復旧することを優先させるために、
xfs_db にてエラー i-nodeの core.mode を 0に変更する。
 write core.mode 0

その後 xfs_repair を行う。
エラーが9箇所、その都度、xfs_db にてcore.modeを修正
 xfs_repair を行う。

lost + found に全てのファイルが見られる。
が、フォルダ名、ファイル名が宇宙語になっている。

しかし、この表示パターン。。。。どこかで見た記憶がある。。。
ん〜〜、あっ！ そうだ、、文字コードの違いだ。
明日は、日本語が"しゃべれる"ディストリビューションにマウントしよう。。


2010年4月20日、フォルダ、ファイルが日本語表示される。
Vine 5.1 にマウント
xfsを扱えるように、insmod /lib/~/xfs.ko
mount -t xfs /dev/mod10 /mnt/data


2010年4月21日、XPで復旧ディスク確認
Captive + cp -r -p でNTFSへ書き込むが、
所有者などの書き込みエラーで低速度なのでSamba経由で行う。

10時間で251Gのファイルコピーが終了
Windows-XPで各フォルダ、各ファイル読み込み確認する。
後に電話連絡

RAIDディスクを整理
内容量0のディレクトリを整理する。
lost+foundのトップディレクトリにあるファイルを種別に分ける。
/etc/fstab にて/dev/md10を/mnt/dataにマウントさせる。
Sambaの設定を行う。


4月22日、納品
RAIDより復旧させたファイルを入れたWindows-XP機の説明
内容量0のディレクトリを整理したVine機よりSamba経由で、7Gのファイルコピーに3時間

外付けディスクへの251Gのコピーを仕込んで帰宅
15時半帰宅

翌日、RAIDにあったファイルが必要な人は、各自、復旧させたファイルを入れたWindows-XP機より、
USBメモリで持ち出しを行うように説明される。



今回も強く思ったこと。
もう一つ、
[globe3.ddns.net] [コンピュータの話へ]