seraphyの日記

日記というよりは過去を振り返るときのための単なる備忘録

cronからのメールで「WARNING: mismatch_cnt is not 0 on /dev/md1」が届いた場合

linux

Software RAID1を組んでいるサーバで、CentOS 5.3 -> 5.4にアップグレードして久しい気がするのだが、
先週アップデートをかけてたせいかはしらないが、今朝はじめて次のような警告メールが届いた。

/etc/cron.weekly/99-raid-check:

WARNING: mismatch_cnt is not 0 on /dev/md1

なんじゃこれは、とググッてみると、ここの情報がとても詳しかった。


[WARNING: mismatch_cnt is not 0 on /dev/md0 | へびにっき]

http://tkyk.name/blog/2009/12/21/CentOS-Server-warning-mismatch_cnt-is-not-0-on-devmd0/
(↑移転されたようなのでURL変更 2014/2/10に気付く)
http://wp.serpere.info/archives/1099


これは5.4で追加修正された新機能らしい。

これは何か?

  1. LinuxのソフトウェアRAIDには、「データスクラビング(Data Scrubbing)」というRAIDアレイを全走査し不良セクタがある場合に他方のアレイ情報からセクタを回復させる機能がある。
    • ただし、5.3までは、この機能は実行されていなかった。
    • 5.4から/etc/cron.weekly/99-raid-check のスクリプトの中で、毎週定時に、それを行うようになった。*1
  2. データスクラビングを行った結果、セクタは正常だがデータの不一致がある場合に、/sys/block/md?/md/mismatch_cnt に、そのセクタ数を報告する。
  3. しかしながら、swapやmemory mapped fileを使用中であれば過渡的な不一致が発生し、それまで検出してしまうことがある。
    • (さらに言えば、ファイルシステム外の領域だったり使用されていない場所であったとしてもチェックはかかるので、もしかしたらゴミの不一致を検知しているかもしれない。)

ということらしい。


どうして、そうゆうことがおきるのか、ということについては「へびにっき」さんのページのリンクの先にあるメーリングリストのアーカイブ
http://marc.info/?l=linux-raid&m=117555829807542&w=2
に書かれていた。

RAID1において、データ不整合が検出されてしまうメカニズム

どうやら、以下のことらしい。

  1. たとえば、メモリマップファイルを作成し頻繁にマップされたメモリを更新すると仮定する。
  2. システムは任意の時点でメモリマップされたデバイスファイルの内容を書き出すことを決定する。
  3. これによりRAID1デバイスに書き出しの要求が行われ、2つの異なるドライブのDMAに、それぞれ書き込み要求が発生する。(これは非同期である。DMAはCPUを介さずメモリをデバイスに転送するための昔からある周辺機能。CPUは開始を指示し終了通知を受け取るだけ。)
  4. それぞれのDMAにより異なる時間にメモリの出力がコントローラに送られるため、それは恐らく異なるデータとなりうる。(2つのDMAへの要求の間にマップドメモリが変更されたなら)
  5. この結果、ミラーリングされた2つのドライブのデータは容易に異なるものになりえる。

つまり、2つのデバイスがまったく同時に同じように転送しているわけではないので、転送元となったメモリの内容が転送中にも変更されつづけている場合には、転送された2つのデバイスの結果も異なることは十分にありえる、ということ。


そして、「RAIDチェック」は、これがまさに発生しているときに、それを検出する、ということのようである。


しかし、これは2つのデバイスの過渡的な状態で、RAID1が正しく動作していれば最終的には同じ内容に落ち着くはずのものである。

  1. 通常、メモリへの書き込みが続けられる限り(ダーティのままであるかぎり)、必要に応じて、そのブロックは何度でも書き込まれる。
  2. メモリへの書き込みを停止すると(ファイルを閉じる、ファイルシステムをアンマウントするなど)、最終的なデータは双方のデバイスに同じデータとして書き込まれる。
  3. これにより、2つのデバイスともに同じ内容で落ち着いた状態で完了する。

RAID1アレイの各デバイスをばらばらに見るのならともかく、RAID1を介した通常のファイルシステムからは、
その時間差による過渡的なRAID1アレイの個々のデバイスのデータ不整合を検知することはできない。
よって、このような過渡的な不整合は、まったくの正常である。


そして、メモリマップドファイルは特にswapで使われているので、
swapを使用中のマシンのRAID1デバイスをチェックすると、いつでも不整合を検知し得るといえる。

結論


上記の情報により、私の場合には、このRAID1デバイスに対する「警告」は警告として受け取っておき放置して問題ないだろうと推測する。

とはいえ定期的な全スキャンそのものは有益であるように思えるのでチェック自身は止めないことにした。
(とめる場合は、/etc/sysconfig/raid-check に SKIP_DEVS="md1" とか書いておけば良いようだ。)


なお、「check」ではなく「repair」を選択することで、不整合をなくすこともできるようであるが、*2 *3
どちらもセクタは正常なので、どっちが正しいのか判断することはできない。結果、どちらかに寄せるかは運任せになる。


そして、上記ケース(上記のswapやメモリマップドファイルの過渡的な状態を検知したのであれば)、せっかくリペアで寄せたあとでも、
すぐに、また書き直されるのであろうから、やっても無害だとは思うが、無駄になってしまう気もする。*4


ということで、私の場合は放置の方向で。

*1:手動でチェックするには、echo check > /sys/block/md1/md/sync_action のように指示する。/proc/mdstatで進行状態が確認できる。

*2:手動でリペアするには、echo repair > /sys/block/md1/md/sync_action のように指示できる。

*3:一応、repairも試してみました。watch 'cat /proc/mdstat; cat /sys/block/md1/md/mismatch_cnt' で進行状態を確認しながら不一致カウントが増えるのを目しできるので、どのあたりかは、なんとなく見当がつけられるかもしれません。

*4:swapや未使用領域で書き込みチャンスがめぐってこない領域は次に書き込まれるまで不一致のままであろうからrepairでそろえる効果はあるかもしれない。でも、使ってない領域とか一時領域なら不一致のままでも問題ないんだよね…。