Ubuntu Linux 10.04 Lucid Lynxで運用中のRAID6ユニットが3つ以上Faultした。その後復旧。

Ubuntu Linux 10.04 Lucid Lynxで運用中のRAID6のデバイスが3つ以上Faultしてしまい動作しなくなくなった。

  • まず mdadm -QE  -scan を実行してmetadataから読み出しが可能か確認。なおハードディスクは10台でRAID6構築。
  • 読み出しはOKだが、mdadm –run /dev/md0 ではInput/Output Errorと表示されて動作しない。
  • cat /proc/mdstat でも/dev/md0は表示されない。
  • mdadm -A /dev/md0 -u UUID値 –run –force で強制的に動作させてもダメ。
  • mdadm -A /dev/md0 /dev/sd[klmnopqrst]1 で更に強制的に動作させても、3つ以上のユニットデバイスがremoved状態で一つがspare状態で復旧しない。
  • 基本に戻って https://raid.wiki.kernel.org/index.php/Linux_Raid を読み直す。
  • https://raid.wiki.kernel.org/index.php/RAID_Recovery に記載されている「Don’t Panic」を心に刻むw
  • https://raid.wiki.kernel.org/index.php/Reconstruction に記載されているmdstat –assemble –force /dev/md0 を実行。
  • すると、cat /proc/mdstat で/dev/md0の情報が表示された。
  • どうやら3つのブロックデバイスが removedになって再構築ができない様だ。
  • 3wareの3dm2をつかってハードディスクの情報をsudo tw_cli /cX showで表示すると4つのデバイスが「Not Presents」と表示されている。どうやらケーブル関連のようだ
  • マシンを停止して、ハードディスクとRAIDボードのケーブルをいくつか交換する。
  • 再起動するとこれまで通り/dev/md0は動作しない。
  • そして mdadm –assemble –force /dev/md0 を打ち込むと、なんとcat /proc/mdstatで/dev/md0デバイスがactiveとなり、Recovery(復旧)モードになった。
  • そのまま現在Recoveryモードで復旧中。
  • なおmountでちゃんとマウントOKである。

これにて復旧終了。3時間かかった。Recovery完了までは5日程度で完了予定。

広告

Linuxカーネル2.6.35がリリースされる。ネットワーク負荷軽減機構やH.264ハードウェアデコードサポート

sourceforge.jp Linuxカーネル2.6.35リリース、ネットワーク負荷軽減機構やH.264ハードウェアデコードなどをサポート

linuxfoundation.jp Linux Weather Forecast より。

新しいLinux カーネル 2.6.35の新機能は主に下記の通り。

  • マルチCPU環境でネットワークスループットを向上させる「Receive Packet Steering(RPS)」および「Receive Flow Steering(RFS)」サポート。なお性能がアップするのは8コア以上からなので個人向けへの影響は今後だろう。
    http://lwn.net/Articles/328339/によると下記のとおり性能がアップ。

    • tg3 on 8 core Intel
      Without RPS: 90K tps at 34% CPU
      With RPS: 285K tps at 70% CPU
    • e1000 on 8 core Intel
      Without RPS: 90K tps at 34% CPU
      With RPS: 292K tps at 66% CPU
    • foredeth on 16 core AMD
      Without RPS: 117K tps at 10% CPU
      With RPS: 327K tps at 29% CPU
    • bnx2x on 16 core AMD
      Single queue without RPS: 139K tps at 17% CPU
      Single queue with RPS: 352K tps at 30% CPU
      Multi queue (1 queues per CPU) 204K tps at 12% CPU
      _
  • SGI開発のカーネルデバッグツール「KDB」の追加
  • メモリの断片化を軽減する「Memory compaction」の追加。使用中のメモリページを連続した大きなページに移動することでメモリ使用効率の改善を図るというもの。近年の大容量メモリ搭載システム向け。
  • カーネルモードセットドライバの改善。IntelのG45チップセットなどが備えるH.264およびVC-1デコード機能、Radeonドライバの各種改良など。
  • Btrfsでファイルシステムのキャッシュを通さずに直接I/Oを行う「Direct I/O」をサポート
  • xfsでI/Oが大量に発生した際の遅延ロギングのサポート
  • perfコマンドの改良
  • multiple multicast route tablesのサポート
  • L2TP Version 3(RFC 3931)のサポート
  • ST-Ericssonのモデムで利用されているCommunication CPU to Application CPU Interface(CAIF)プロトコルのサポート
  • ACPI Platform Error Interfaceのサポート(先日のUbuntu Linux 10.10 Maverick Meeakatのニュース参照)
  • Linux Software RAIDのRAID0⇔RAID10,RAID4,RAID5の引継ぎが可能になった。ただしRAID6については記述なし。
  • AMDの新CPU PhenomII X6 1090Tなどで採用された動作コアを減らす代わりに動作クロックを上げる「Turbo CORE」対応のCPUでpowernow-k8の「Turbo Boost」制御が可能となる。

2010年8月2日現在Ubuntu Linux kernel-ppa mainlineには2010年7月31日ビルドバージョンがある。

Linux kernel Changelog 2.6.35の解説は下記のページを参照。

http://kernelnewbies.org/Linux_2_6_35

Westerndigital製ハードディスク WD20EARS-00S8B1(500GBプラッタ)の代替保留セクタ数が26に

現在Ubuntu Linux 10.04 Lucid LynxでRAID6アレイで利用中のWesterndigital製WD20EARS-00S8B1(500GBプラッタ)だが、購入したうちの1台が1ヶ月半で代替保留セクタ数が26を数えた。syslogに出力された値は下記の内容。

26 Currently unreadable (pending) sectors

最初は当然0だったが、13→26と非連続で増加している。これは初期不良品にあったのだろうかと思案中。

追加 2010年7月21日〜23日

代替保留セクタが増加しているハードディスクWD20EARSで回復不能なセクタをsyslogに出力していた。

2 Offline uncorrectable sectors

ハードディスク表面に傷がついている可能性大。だが購入したハードディスクの代理店はCFDなので、SMART値変化・劣化は交換保証外だからなぁ。

…と現在23時10分。代替保留セクタが593セクタとでた。もうダメだろう。

更に22日で代替不能セクタが543セクタに増加。来月まで持ちますように…。

と23時7分で代替保留セクタ数が596セクタ。おいおいあと10日持つのか?

23日現在、代替保留セクタが596セクタである。syslogがtimeoutエラーを吐き出しているのでSATAケーブルの問題と確信する。抜けやすくなったSATAケーブルのメスコネクタを無理矢理復活させる方法で挿し直すとピタリとエラーが止まる。550円もしたSATAケーブルが80円のSATAケーブルよりエラー率が高いという寂しい結果となった。

Ubuntu Linux 10.04 Lucid Lynxのカーネルでタイムアウトでハングアップしたとログが表示される

Ubuntu Linux 10.04 Lucid Lynxのsyslogに大量にカーネルログが吐き出されていた。

以下の通り。

Jul  9 14:06:07 server kernel: [13200.403026] INFO: task jbd2/dm-0-8:1311 blocked for more than 120 seconds.
Jul  9 14:06:07 server kernel: [13200.403032] “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message.
Jul  9 14:06:07 server kernel: [13200.403036] jbd2/dm-2-8   D ffff8800805a9880     0  1311      2 0x00000000
Jul  9 14:06:07 server kernel: [13200.403042]  ffff880186b65d30 0000000000000046 ffff88005d173430 ffff880188f64f50
Jul  9 14:06:07 server kernel: [13200.403048]  ffff880186b64000 ffff880186b65fd8 0000000000015bc0 ffff880186b65fd8
Jul  9 14:06:07 server kernel: [13200.403054]  ffff880196c15bc0 ffff880196c15f80 ffff880186b65fd8 0000000000015bc0
Jul  9 14:06:07 server kernel: [13200.403059] Call Trace:
Jul  9 14:06:07 server kernel: [13200.403071]  [<ffffffff8122aa75>] jbd2_journal_commit_transaction+0x1c5/0x12c0
Jul  9 14:06:07 server kernel: [13200.403078]  [<ffffffff815696e9>] ? sub_preempt_count+0x9/0xa0
Jul  9 14:06:07 server kernel: [13200.403082]  [<ffffffff81566561>] ? _spin_unlock_irq+0x21/0x50
Jul  9 14:06:07 server kernel: [13200.403088]  [<ffffffff810580a0>] ? finish_task_switch+0x50/0xd0
Jul  9 14:06:07 server kernel: [13200.403092]  [<ffffffff815696e9>] ? sub_preempt_count+0x9/0xa0
Jul  9 14:06:07 server kernel: [13200.403095]  [<ffffffff8156651c>] ? _spin_unlock_irqrestore+0x2c/0x50
Jul  9 14:06:07 server kernel: [13200.403100]  [<ffffffff81089190>] ? autoremove_wake_function+0x0/0x40
Jul  9 14:06:07 server kernel: [13200.403106]  [<ffffffff81232747>] kjournald2+0xb7/0x210
Jul  9 14:06:07 server kernel: [13200.403110]  [<ffffffff81089190>] ? autoremove_wake_function+0x0/0x40
Jul  9 14:06:07 server kernel: [13200.403114]  [<ffffffff81232690>] ? kjournald2+0x0/0x210
Jul  9 14:06:07 server kernel: [13200.403118]  [<ffffffff81088da6>] kthread+0x96/0xa0
Jul  9 14:06:07 server kernel: [13200.403123]  [<ffffffff810142da>] child_rip+0xa/0x20
Jul  9 14:06:07 server kernel: [13200.403128]  [<ffffffff81088d10>] ? kthread+0x0/0xa0
Jul  9 14:06:07 server kernel: [13200.403132]  [<ffffffff810142d0>] ? child_rip+0x0/0x20

要はRAIDブロックデバイスが120秒間返答なしでタイムアウトでハングしたということらしい。

ハードディスクを確認したところ故障の兆候はなく、単純にファイルコピーの容量が大きくて時間がかかっているときに吐き出されているようだ。そこで下記のURLを参考にsyslog表示を止めた。

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517586

方法はsyslog中にも出力されているが、下記の通り。

$ sudo -s

$ echo 0 > /proc/sys/kernel/hung_task_timeout_sec

これでsyslogにカーネルのタイムアウトハングアップのメッセージは表示されなくなる。

PCルームwの室温が34℃を記録

私の部屋は北向き3畳の小さな部屋だが、換気状況が悪いため気温が上がりやすい。

6月28日20時47分現在の室温は34℃、湿度68%である。

別の部屋のエアコンで冷えた空気を循環させている状態の温度。

PCの各部位の温度は下記の通り。

  • CPU 59℃ (Phenom X4 9750 リテールクーラー)
  • M/B 42℃ (Asus M2A-VM 690Gチップのヒートシンクに向けて10センチファンで冷却)
  • HDD 36℃〜41℃ 平均38℃

ハードディスクは40℃を超えているのは1台のみで冷却に関してはまあまあである。

AMD 690Gチップは40℃を超えるとフリーズしやすくなるため不安ではある。

しかし人にとっては大変暑い。熱中症に気をつけよう。

WesternDigital製HDD WD20EARSの667GBプラッタのベンチマーク

先日購入したWesternDigital製のハードディスク WD20EARS-00MVWB0 667GプラッタバージョンをUbuntu Linux 10.04 Lucid Lynx に接続した。接続環境は下記の通り。

CPU : Phenom X4 9750

M/B : Asus M2A-VM ( AMD 690G, SB600 )

OS : Ubuntu Linux 10.04 LTS Lucid Lynx ( kernel 2.6.31-21 )

ベンチマークはGNOME標準のPalimpsest ディスク・ユーティリティ 2.30.1を利用。

WD20EARS-00MVWB0ベンチマーク

平均読み込み速度が94.0MB/sなのでなかなかの速度である。

なおこのハードディスクを既に構築されているRAID6アレイ(合計10台)に追加したところ、reshape完了は4.8日後とのこと。

のんびり待つことにする。

WesternDigital製HDD WD20EARSの667GBプラッタバージョンを購入

ツクモオンラインショップ よりタイムセールで2TBのWesnternDigital製ハードディスクWD20EARS 667GBプラッタ×3枚バージョンを8,980円で購入した。到着したらUbuntu Lucid Lynx 10.04 マシンの3ware 9500s-12 に接続してRAID6に追加する予定。

なおWD20EARSの従来500Gプラッタと新667GBプラッタの違いは下記の通り。

  • 新667GBプラッタはWD15EARSの外装で基板レイアウトも同じらしい。
  • プラッタ枚数が4枚から3枚に減少。
  • プラッタの軸端にディクスがぶれない様に固定するStableTracが無い(4プラッタのみのため)
  • 消費電力は同じか微増。
  • AFT(Advanced Format Technology)やヘッダ退避機構IntelliPark、省電力機構IntelliPowerは従来と同様。
  • 回転数はIntelliPowerの為可変なので非公開だが、従来と同じ5000RPM前後らしい。

従来RAIDアレイは性能や相性問題回避のため同じメーカー・型番のハードディスクが良いとされていた。

ハードディスクの性能のボトルネックが解消された今、同じ環境で運用しているRAIDアレイで、特定メーカー・型番のハードディスクを集中して利用すると故障原因や平均故障時間が同じように集中しやすいという経験がある。

なので私は適度にメーカーや型番を分散させたハードディスクを利用してRAIDアレイを構築している。

Ubutnu 10.04 Lucid Lynx にてWD20EARS&WD20EADSの9台RAID6の拡張完了に5日間費やす

Ubutnu 10.04 Lucid Lynx にてWD20EARS&WD20EADSの9台RAID6の拡張がようやく明日に完了する予定。やはり3ware 9500s-12をPCI 32bit 33MHz接続ではバス帯域が足りないので実測値110MB/secしかでないので5日間もかかる。

またカーネ ルを2.4.34-999(nightly Build)にアップした。Promise SuperTrak ex8350ドライバのstex不具合等があれば記載する予定。

Ubuntu Linux 10.04 Lucid LynxでLVM・ext4区画の拡張を行う

Ubuntu 10.04 Lucid LynxのRAID6にハードディスクを追加の続き。

RAID6の拡張が終わったので、区画の拡張を行う。Linuxでは、RAID6+LVM+ext4の組み合わせではマウントしたままの状態で容量の拡張(オンライン拡張)が可能である。

$ sudo pvs -v
Scanning for physical volume names
PV         VG      Fmt  Attr PSize   PFree   DevSize PV UUID
/dev/md0   Array00 lvm2 a-     5.46t      0 9.10t eAZgg9-1tAW-XY36-UmBc-LjGn-HXiG-aiIvZF

$ sudo pvresize -v /dev/md0
Using physical volume(s) on command line
Archiving volume group “Array00” metadata (seqno 2).
Resizing physical volume /dev/md0 from 1430795 to 2384659 extents.
Resizing volume “/dev/md0” to 19535131392 sectors.
Updating physical volume “/dev/md0”
Creating volume group backup “/etc/lvm/backup/Array00” (seqno 3).
Physical volume “/dev/md0” changed
1 physical volume(s) resized / 0 physical volume(s) not resized

これでPVが拡張で来たかを確認する。

$ sudo pvs -v
Scanning for physical volume names
PV         VG      Fmt  Attr PSize   PFree   DevSize PV UUID
/dev/md0   Array00 lvm2 a-     9.10t   3.64t 9.10t eAZgg9-1tAW-XY36-UmBc-LjGn-HXiG-aiIvZF

PV拡張完了。RAID6上のPVを拡張すると自動的にVGの容量も拡張される。次にLV区画をVG容量いっぱいまで拡張する。

$ sudo lvextend -l +100%VG /dev/mapper/Array00-lv00
Extending logical volume lv00 to 9.10 TiB
Logical volume lv00 successfully resized

ここまではコマンド実行と共に数秒で完了する。最後にext4区画をresize2fsを使って拡張する。

$ sudo resize2fs /dev/mapper/Array00-lv00

Filesystem at /dev/mapper/Array00-lv00 is mounted on /mnt/disk020; on-line resizing required
old desc_blocks = 350, new_desc_blocks = 583
Performing an on-line resize of /dev/mapper/Array00-lv00 to 2441890816 (4k) blocks.
The filesystem on /dev/mapper/Array00-lv00 is now 2441890816 blocks long.

3時間ほどで拡張完了。

$ df -h -T -P

/dev/mapper/Array00-lv00 ext4  9.0T  4.5T  4.1T  53% /mnt/disk020

容量も無事増加。

2010年5月7日から5月19日まで延べRAID6の構築に12日間かかったことになる。大部分は待ち時間であったが、RAIDアレイの拡張中(reshape)にハードディスクが1台故障するというトラブルが無ければ2日程度は短くなっただろう。

…と思ったら故障したハードディスクの交換品が今日宅配便で到着した。これからまたRAIDアレイの拡張作業に10日かかるんだな…。

Ubuntu 10.04 Lucid LynxでRAID6構築 更新2010/06/19

※注意:コマンドラインはあくまで参考です。環境によりパラメータが異なります。またエディタの関係上一部記号がコピー&ペーストできません。自己責任でおねがいします。

先日ネットショップで購入したWD20EARSが我が家に到着した。

5台購入。代理店はCFDの1年保証。ウェスタンデジタル日本語ページのエンドユーザ保証サービスのページから、保証の確認を行うと、5台とも全て「限定保証なし」とつれない回答。

そこでRMAの3年保証を有効にするために、CFDのWesternDigital RMA申請開始手続きページから台数分のRMA有効の申請を行う。ちょっと面倒な作業。10日前後で手続きが完了とのこと。

次にUbuntu 10.04マシンに3ware 9500S-12経由で購入したハードディスク5台を追加接続して起動。

9500S-12はSATA1.5Gbit/secなのだが、8/10シリアルで換算して1台あたり100MB/secも速度が出れば充分なのと、PCI33MHz32bitなので133MB/secが限界値であること、さらにdebianやfedoraなどのイメージ記録用なので問題なしと判断した。

Ubuntu起動後にpalimpsestディスク・ユーティリティで全てのハードディスクが認識していることを確認。

そのままRAID構築でも良いが念のためパーティションを設定する。

GPTパーティションの作成

GPTパーティションを利用するのでfdiskではなくpartedを利用する。

$sudo parted /dev/sdq

$mklabel gpt

パーティションテーブルにGPTを利用する。

$unit MiB

パーティション作成時の単位をMiB(1,024bytes * 1,024  = 1,048,576 bytes)にする。

これは、WD20EARSがAdvanced Format Technology(AFT)を利用したハードディスクだからである。内部のセクタは4KiB(4096bytes)だが、セクタエミュレーションにより512bytesセクタに見せかけている。WindowsXP以前のOSは512bytesセクタに決め打ちしているため互換性を保つためと、セクタサイズを大きくしてもECC(エラー訂正符号)のbit数は比例せず同じ記録密度でディスク容量が最大11%アップするため導入したらしい。またエミュレーションセクタの境界と内部セクタの境界にズレが生じると性能が劣化する(最大2回の読み書きが生じるため)ので、パーティション境界を8の倍数のセクタに合わせておく必要がある。

$ mkpart ext4 1 -1

先頭パーティションを1MiBから開始するようにパーティションを設定する。

$ set 1 raid on

作成したパーティションにLinux RAIDフラグを設定する。

$ quit

この作業を5台分行う。

RAID6の構築

$ sudo mdadm –create /dev/md0 –raid-device=5 –level=6 –metadata=1.0 –chunk=128 –layout=left-symmetric-6 –bitmap=internal  /dev/sd[pqrst]1

長いので分けて解説する。

$ sudo mdadm –create /dev/md0

新規にディスクアレイ(RAID)を作成する。デバイス名をmd0とする。

–raid-device=5

RAIDに利用するハードディスク(デバイス)の数を設定する。

–level=6

RAIDレベルの設定。RAID0(冗長性なし・ストライピング)、RAID1(ミラーリング)、RAID5(1台分の冗長性)、RAID6(2台分の冗 長性)となる。その他にもRAID1の3重ミラーリングやRAID1+0など用途に応じて設定。

–metadata=1.0

LinuxのRAIDは、起動時に自動認識してRAIDデバイスを利用可能な状態にする。その際のRAIDに関する情報(metadata)を記録するのだが、バージョンと記録する位置によりいくつか設定がある。

0.9:ハードディスクの最後にmetadataを記録する。なお古いバージョンのため、1RAIDボリュームあたり2TiBまでなど制限がある。

1.0 1.1 1.2:metadataのバージョンは全て1.0で、小数点以下によりハードディスクの最後・ハードディスクの先頭・ハードディスクの先頭から4KiBとなる。

–chunk=128

単位はKiB。RAIDボリュームから読み出す単位を設定する。標準は64KiB。RAID5・6は128KiBが適切らしい。

–layout=left-symmetric

RAIDボリュームを構成するハードディスクの先頭からデータを書込み、最後にパリティ情報を記録する。詳細は別途検索をお願い。

–bitmap=internal

RAIDボリューム単位で更新情報を記録する。標準はnone。リカバリ時にbitmapの内容を参照して再構築に必要な部分のみを構築するため、時間短縮につながる。

/dev/sd[pqrst]1

続けて構築するハードディスクデバイス名を列挙する。

コマンドは実行すると2~3秒程で終了するが、バックグラウンドジョブで稼働している。

進捗状況を表示するには下記のコマンドで可能。

$ watch -n 1 cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdt1[4] sds1[3] sdr1[2] sdq1[1] sdp1[0]
5860539648 blocks super 1.0 level 6, 128k chunk, algorithm 2 [5/5] [UUUUU]
[>………………..]  resync =  4.5% (89325056/1953513216) finish=1490.8min speed=20840K/sec
bitmap: 446/466 pages [1784KB], 2048KB chunk

unused devices: <none>

などと表示される。resync=4.5%が構築の進捗状況。RAID再構築が完了してmd0デバイスが利用可能になるまで24時間強である。

RAID構築完了後詳細表示を行う。

$ sudo mdadm –detail /dev/md0

/dev/md0:
Version : 01.00
Creation Time : Fri May  7 18:10:52 2010
Raid Level : raid6
Array Size : 5860539648 (5589.05 GiB 6001.19 GB)
Used Dev Size : 3907026432 (3726.03 GiB 4000.80 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Sat May  8 23:57:37 2010
State : active
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0

Chunk Size : 128K

Name : momoserver:0  (local to host momoserver)
UUID : f246dae2:6b221399:fea2f6a8:5e7dfdd2
Events : 20404

Number   Major   Minor   RaidDevice State
0       8      241        0      active sync   /dev/sdp1
1      65        1        1      active sync   /dev/sdq1
2      65       17        2      active sync   /dev/sdr1
3      65       33        3      active sync   /dev/sds1
4      65       49        4      active sync   /dev/sdt1

ここではChunk Size : 128Kを覚えておく。

LVM(Logical Volume Managementの設定

/dev/md0構築後直ぐにmkfs.ext4でも良いのだが、気分的にLVMを構築してからにする。

$ sudo vgcreate Array00 /dev/md0

PVとVGを同時に作成する。Array00はボリュームグループ名(VG)、/dev/md0以降は VGに参加させるデバイス(PV)を列挙する。

Volume group “Array00” successfully created

作 成すると上記のメッセージを表示する。

次にロジカルボリューム(LV)を作成する。これが実質的なパーティション名となる。

$ sudo vgdisplay -v Array00

作成したVGの詳細表示。

Using volume group(s) on command line
Finding volume group “Array00”
— Volume group —
VG Name               Array00
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  1
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                0
Open LV               0
Max PV                0
Cur PV                1
Act PV                1
VG Size               5.46 TiB
PE Size               4.00 MiB
Total PE              1430795
Alloc PE / Size       0 / 0
Free  PE / Size       1430795 / 5.46 TiB
VG UUID               PGcd8f-w2nM-22he-GRPl-y6Wr-kgyP-Mw3N6P

— Physical volumes —
PV Name               /dev/md0
PV UUID               eAZgg9-1tAW-XY36-UmBc-LjGn-HXiG-aiIvZF
PV Status             allocatable
Total PE / Free PE    1430795 / 1430795

PEとは、Physical Extentの略で、LVMで扱う情報の最小単位と思えばいい。

デフォルトでは1PE=4MiBなので、Total PE 1430795×4MiB=5590GiBとなる。

ここで最後に論理ボリューム(Logical Volume)の作成を行う。

$ sudo lvcreate -l 100%VG -n lv00 Array00

最後のパラメータにLVに追加するVGを列挙する。

-l 100%VG

これはVGの容量の100%で作成するというパラメータ。

-n lv00

LV名の設定

Logical volume “lv00” created

これでLVMの設定は完了。

ext4でLVをフォーマット

$ sudo mkfs.ext4 /dev/Array00/lv00

ここでext4フォーマットを行う。

Invalid argument 100%VG
Error during parsing of command line.
mtama@momoserver:~$ sudo lvcreate -l 100%VG -n lv00 Array00
Logical volume “lv00” created
mtama@momoserver:~$ sudo mkfs.ext4 /dev/Array00/lv00
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=32 blocks, Stripe width=96 blocks
366288896 inodes, 1465134080 blocks
73256704 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
44713 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544

Writing inode tables:   399/44713

フォーマットしている間に/dev/md0を自動認識させるよう設定する。

$ sudo mdadm -Ds /dev/md0

ARRAY /dev/md0 level=raid6 num-devices=5 metadata=01.00 name=momoserver:0 UUID=f246dae2:6b221399:fea2f6a8:5e7dfdd2

$ sudo mdadm -Ds /dev/mdo >> /etc/mdadm/mdadm.conf

次に手作業でmdadm.confを編集する。

$ sudo vi /etc/mdadm/mdadm.conf

# definitions of existing MD arrays
ARRAY /dev/md0 name=server:0 metadata=01.00 UUID=XXXXXX auto=yes

下線部をmetadata=1.0に書き換える。

マウントして完了

フォーマットが終わると下記のメッセージが表示される。

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

マウントする。

$ sudo mount -t ext4 /dev/Array00/lv00 /mnt/disk/

次に自動マウントするためfstabを編集する。

$ sudo vi /etc/fstab

下記の行を追加する。

# RAID6 LVM2 Array00
/dev/Array00/lv00        /mnt/disk    ext4    rw,auto,noatime 0       2

最後の数字はfsckをどのタイミングで行うか。詳しくは検索すること。

これで完了。

作業時間は1時間弱、作業期間は4日程度であった。次回はディスクの増設を行う予定。

RAID構築後にRAIDユニットがマウントできない場合 2010年06月06日追加

何かの表紙でRAIDボードやSATAデバイスのドライバがエラーを起こした場合、ハードディスクは正常なのにArray StatusがFaildとなってアレイをマウントできなくなる場合がある。

その際に有効なコマンドをいくつかメモする。

$ sudo mdadm -QE –scan

ARRAY /dev/md/2 level=raid5 metadata=1.0 num-devices=3 UUID=5cbbccda:b3b74458:8f193a8e:d66021d8 name=server:2
ARRAY /dev/md/1 level=raid5 metadata=1.0 num-devices=4 UUID=0aeedf27:e5a4d11e:44d6b3de:5aa5e901 name=server:1
ARRAY /dev/md/0 level=raid6 metadata=1.0 num-devices=9 UUID=f246dae2:6b221399:fea2f6a8:5e7dfdd2 name=server:0

mdadm.confに間違ったUUIDを記載した場合に正常なUUID値をハードディスクのスーパーブロックから読み出すコマンド。

出力されたリストをmdadm.confに追加するだけで良い。

$ sudo mdadm -As /dev/md0

mdadm.confに記載されたmdデバイスを開始する。

$ sudo mdadm -E /dev/sdc1

ハードディスクのスーパーブロックからRAID情報を読み出す。古いRAIDアレイで利用していたハードディスクを再利用使用する際に、UUIDが古いままだと新しいRAIDアレイに追加できない。-QEコマンドと使うとUUIDを比較して正しいか判断ができる。