カテゴリー別アーカイブ: Linux

4KBセクタのことを考えずにパーティション切っちゃってたことに気づいて何とか切り直そうとしてみる

最近4KBセクタのHDD増えましたよね。
ってか割と今更感もあると感じる人も多いかと思うけど、実際のところうちのサーバ機の構成HDDはちょっと前まで4KBセクタのHDDは混じってなかったんです。
でも、HDDの寿命やら故障やらで交換してたら、気づかぬうちに6 本中3本が4KBセクタものになっていました。
そして、そのことに気づいたのが昨日。

さて、パーティションは普通にfdiskで切ってましたよ、ええ。
パーティション開始位置みたら先頭パーティションおもいっきり63セクタですよええ。

ということで、パーティションを切り直す必用がある、というか、必用ではないけど切り直した方がいいのは間違いないわけで。

あ、何が問題なのかわからない人のために一応4KBセクタのお話をすっげー簡単にしておきます。
HDDは基本的に一セクタ512byteでした。
でも大容量化に伴い、一セクタ512byteだと非効率になってきたんで、一セクタ4KiBのHDDが出てきました。
なんだけど、BIOSとかドライバとかまあ根本的なところがHDDの一セクタは512byteっていう前提のものがまだまだ多いんで、内部的には4KiBだけど外面は今まで通り512byteな奴らが出てきました。
でもその関係でなんも考えずに従来通りのパーティション切りをしてると、書き込み性能が低下することがある問題が発生しました。
これ以上詳しい話はこちらのエントリをご覧ください。
そして今まさにその状態なわけです。

さて、そうすると、まず何をしなければならないか。
今のHDDの内訳を作ろう。

sda – ST2000DL003-9VT166
sdb – ST2000DL003-9VT166
4KBセクタ
/bootをミラーリングで構築
各種システムパーティションをLVMミラーで構築
各1.5TずつファイルサーバのRAID5へ組み込み

sdc – WDC WD10EADS-00M2B0
非4KBセクタ
バックアップ用

sdd –  WDC WD15EADS-00P8B0
sde – WDC WD15EADS-00S2B0
sdf – WD15EARS
sdfが4KBセクタ
ファイルサーバ用でRAID5くんでる
このうちsdfは不良により現在失踪中

んーと。
とりあえずRAID5が致命的にやばそうなんだが。。。
sdaの状態を確認してみる。
単位はシリンダじゃなくてセクタに変更してある。

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      546209      273073+  fd  Linux raid autodetect
/dev/sda2          546210   976751999   488102895   8e  Linux LVM
/dev/sda3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

はい、第一、第二パーティション開始セクタが8の倍数じゃないですね。
んーと。
sda1の開始位置を64にして終了位置を546199に
sda2の開始位置を546200にして終了位置はこのまま
とかやれれば良さそうだ、とりあえず。
ところで今までresize2fsとか結構やってきたけど、それで変わるのってパーティションの終了位置なんだよね。
開始位置の変え方を知らないことに気がついた。

で、resize2fsのmanページにこんなことが書いてある。

resize2fs プログラムは、パーティションのサイズは操作しない。 ファイルシステムを大きくしようとする場合は、 そのファイルシステムがあるパーティションのサイズを大きくできるかを 最初に確認しなければならない。 これは、 fdisk(8) を使ってパーティションを削除した後に より大きなパーティションを再作成することで確認できるし、 論理ボリュームマネージャ lvm(8) を使っている場合は、 lvextend(8) を使って確認できる。 パーティションを再作成する場合、 必ず以前と同じ開始ディスクシリンダで作成すること! そうしないと、サイズ変更の操作は絶対にうまく行かず、 ファイルシステム全体を失ってしまう。 fdisk(8) を実行した後、resize2fs を実行すること。 これにより、ext2 ファイルシステムのサイズを変更し、 拡大した新しいパーティションの全ての領域を使うことができる。

あ、はい。
要するに、一回ファイルシステム消せってことですね、わかります。
とりあえずRAID5の構成要素である第3パーティションはふれないでいいのは幸いだった。
ほんと1/8の偶然。

ということでまずシステムのバックアップとる。
sdb1, sdb2のパーティションを切り直す。

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048      546199      272076   fd  Linux raid autodetect
/dev/sdb2          546200   976751999   488102900   8e  Linux LVM
/dev/sdb3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

再起動。
死んだ。
LVMボリュームがみつからねーっていわれた。
ブートしない。
さすがに無茶だったか。
LVMのミラーリングってじゃあ役に立つのか?
どうせミラーリングするんだからmdにしてしまいたいな。
まあ、この展開になったならもういいわ。
レスキューモードに入ってsda1とsda2のパーティションもぶった切る。
ということでぶった切り。
sda2もLVMじゃなくてLinux RAID autodetectに変更。
で、論理ボリュームとかぼこぼこ削除していったら、vgremoveがうまくいかず、vgreduce –removemissingをしてみろてきな。
あれ、もしかしてこれやれば良かった?
でももうおそい、あとには引けない。
削除。
そして綺麗に掃除したあと、アレイを作り直す。

# mdadm --create /dev/md1 -l1 -n2 --metadata=0.9 /dev/sd[ab]1
# mdadm --create /dev/md2 -l1 -n2 /dev/sd[ab]2

md1にファイルシステムを作ってバックアップを流し込む。
md2はLVMに。

# pvcreate /dev/md2
# vgcreate ms09 /dev/md2
# lvcreate -L 32G -n ms09 ms09

あとはmke2fsしてバックアップから流し込む。

これでとりあえずsdaとsdbはおっけー。

と思ったら起動しない。
grub loading
error 17
でました。
update-grubでいけるかと思ったけど駄目だったのでインストールし直す。
grubの画面までいくようになったけど今度はカーネル選択するとUnknown filesystemでマウントできないっていってerror 17。
レスキューから確認するとmd1がsdb1の方肺になっててgrubはsda1(hd(0,0))みにいってたっていうことでした。
まじね。
ということでmdadm /dev/md1 -a /dev/sda1して同期かけてgrubコマンドで確認して認識したので再起動。
漸くブートきたと思ったら、rootファイルシステムがみつからねーよっていうかmdadmでRAID ARRAY起動失敗っつーてこける。
きてる、きてるよくそはまりパターン。
んーと、なにをやりのがしてる?
んー、initramfsか?initramfsだろ。

update-initramfs -uk ‘all’

と。
はあ、やっと起動した。

とりあえず一旦ここで休憩。

exim4でmailコマンドの送信を他のSMTPサーバに任せる

ふと気づいたんだけども、DomUの一つでmailコマンドが存在しないことに気づいた。
消したのか元々入ってなかったのか。
ということで使えるようにする必用がある。

debianではmailコマンドはmailutilパッケージに含まれるらしい。
ということで、

# aptitude install mailutils

これでメール送れるはずだとおもってテストしてみる。

# mail test@example.com
Cc:
Subject: test
test

おや。
届かない。
おかしい。

キューに残ってる。

で、exim4の設定を本格的にやる気はない、というかDomU(U1)から配送するのは基本的にシステムメールだけな予定。
なので、別のDomU(U2)でうごいているPostfixさんに配送を任せようということに。

# dpkg-reconfigure exim4

メールサーバ設定形式でスマートホストを使う
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x 必要とするものに最適と思われるメールサーバ設定形式を選択してください。              x
 x                                                                                     x
 x ダイヤルアップシステムなどの動的 IP アドレスのシステムでは、一般に送出するメールを  x
 x 配信のために別のマシン (「スマートホスト」と呼ばれる) に送るよう設定すべきでしょう  x
 x 。インターネット上の受信システムの多くは、迷惑メール対策として動的 IP アドレスから  x
 x やってくるメールをブロックしているからです。                                        x
 x                                                                                     x
 x 動的 IP アドレスのシステムは、自身のメールを受け取るようにするか、ローカル配送を    x
 x (root と postmaster へのメールを除き) すべて無効にするかできます。                  x
 x                                                                                     x
 x メール設定の一般的なタイプ:                                                         x
 x                                                                                     x
 x            インターネットサイト; メールは SMTP を使って直接送受信される             x
 x          ○ スマートホストでメール送信; SMTP または fetchmail で受信する             x
 x            スマートホストでメール送信; ローカルメールなし                           x
 x            ローカル配信のみ; ネットワークなし                                       x
 x            今は設定しない                                                           x
 x                                                                                     x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

自分のサーバ名を入れておくのがまあ普通。
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x 「メール名」は、ドメイン名がないときにメールアドレスを「修飾」するために使われるド  x
 x メイン名です。                                                                      x
 x                                                                                     x
 x この名前はほかのプログラムによっても使われます。これは、単一の完全修飾ドメイン名    x
 x (FQDN) にすべきです。                                                               x
 x                                                                                     x
 x たとえば、ローカルホストのメールアドレスが foo@example.org の場合、ここで入力する   x
 x 正しい値は example.org となるでしょう。                                             x
 x                                                                                     x
 x 書き換えを有効にすると、この名前は送出するメッセージの From: 行に出現しません。     x
 x                                                                                     x
 x システムメール名:                                                                   x
 x                                                                                     x
 x U1.waterblue.net___________________________________________________________ x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

ローカルからのメールしか送らないので、ローカルを指定
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x IP アドレスのリストをセミコロンで区切って指定してください。Exim SMTP リスナデーモ   x
 x ンは、ここで挙げられたすべての IP アドレスをリスンします。                          x
 x                                                                                     x
 x この値を空にすると、Exim はすべての利用可能なネットワークインターフェイスの接続を   x
 x リスンするようになります。                                                          x
 x                                                                                     x
 x このシステムが (ほかのホストからではなく) ローカルサービスから直接メールを受け取る  x
 x のであれば、ローカルの Exim デーモンへの外部からの接続を禁止するのもよいでしょう。  x
 x このようなサービスには、fetchmail 同様にローカルホストとやり取りする電子メールプロ  x
 x グラム (MUA) も含まれます。ここで 127.0.0.1 と入力すると、パブリックなネットワーク  x
 x インターフェイスのリスニングを無効にするので、外部から接続できなくなります。        x
 x                                                                                     x
 x 入力側 SMTP 接続をリスンする IP アドレス:                                           x
 x                                                                                     x
 x 127.0.0.1 ; ::1____________________________________________________________________ x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

受信先になる気もないのでデフォルトで十分
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x このマシン自身が最終的な宛先と見なされるべきドメインのリストをセミコロンで区切って  x
 x 指定してください。これらのドメインは一般に「ローカルドメイン」と呼ばれます。ローカ  x
 x ルホスト名 (fileserver.waterblue.net) および 'localhost' は常にこのリストに追加さ   x
 x れます。                                                                            x
 x                                                                                     x
 x デフォルトでは、すべてのドメインは同一のものとして扱われます。a.example と          x
 x b.example の両方がローカルドメインである場合、acc@a.example と acc@b.example は同   x
 x じ最終宛先に配送されます。異なるドメイン名を別々のものとして扱いたいときには、設定  x
 x ファイルをあとで編集する必要があります。                                            x
 x                                                                                     x
 x メールを受け取るその他の宛先:                                                       x
 x                                                                                     x
 x ___________________________________________________________________________________ x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

リレーする気もないのでデフォルトで十分
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x このシステムがスマートホストの役割としてメールを無条件にリレー可能な IP アドレス範  x
 x 囲のリストを、セミコロンで区切って指定してください。                                x
 x                                                                                     x
 x 標準的なアドレス/長さのフォーマットを利用すべきです (たとえば 194.222.242.0/24 や   x
 x 5f03:1200:836f::/48)。                                                              x
 x                                                                                     x
 x このシステムをほかのホスト向けのスマートホストにしようとするわけではないなら、この  x
 x リストを空のままにしておいてください。                                              x
 x                                                                                     x
 x メールをリレーするマシン:                                                           x
 x                                                                                     x
 x ___________________________________________________________________________________ x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

送信を委託するサーバを指定。
ちなみにここにgmailを指定したりもできるらしい。
smtp.gmail.com:587
を指定すればいいらしいけど試してない。
外部送信専用ならgmail指定するのも良いんじゃないでしょうか。
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x このシステムが送出スマートホストとして使うメールサーバの IP アドレスまたはホスト名  x
 x を指定してください。スマートホストが TCP/25 とは異なるポートからのみのメールを受け  x
 x 付けるのであれば、2 つのコロンとポート番号を追加してください (あとえば              x
 x smarthost.example::587 あるいは 192.168.254.254::2525)。IPv6 アドレスでのコロンは   x
 x さらに二重にする必要があります。                                                    x
 x                                                                                     x
 x スマートホストが認証を必要とする場合、SMTP 認証のセットアップについて書かれた       x
 x Debian 固有の README ファイルを参照してください。                                   x
 x                                                                                     x
 x 送出スマートホストの IP アドレスまたはホスト名:                                     x
 x                                                                                     x
 x U2.waterblue.net_________________________________________________________________ x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

自分の場合はどのシステムからのメールか必用なのでいいえ。
ローカル用途ではなく、外部に向けて使う場合ははいを選びましょう。
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x                                                                                     x
 x 異なるシステムで生成されたかのように見えるよう、送出するメールのヘッダは書き換えで  x
 x きます。ここで「はい」と答えると、From、Reply-To、Sender、Return-Path の            x
 x 'fileserver.waterblue.net'、'localhost'、'' が置き換えられます。                    x
 x                                                                                     x
 x 送出するメールでローカルメール名を隠しますか?                                       x
 x                                                                                     x
 x                        <はい>                          <いいえ>                     x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

ネットワーク接続が定額制ならいいえで問題ない。
未だに従量制ならはいにしたほうが節約になる。
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x                                                                                     x
 x 通常の動作モードでは、Exim は起動時、およびメッセージの受信時と配送時に DNS ルック  x
 x アップを行います。これは、記録用であり、設定ファイルにハードコードされた値の数に抑  x
 x えることができます。                                                                x
 x                                                                                     x
 x このシステムが完全な DNS サービスリゾルバを常時利用できない場合 (たとえばインター   x
 x ネットアクセスがダイヤルアップオンデマンドを使ったダイヤルアップ回線の場合)、これ   x
 x は望ましくない結果となり得ます。たとえばExim の起動時やキューの実行時 (待機中のメ   x
 x ッセージがないときでも) に、コストの高いダイヤルアップイベントを引き起こす恐れがあ  x
 x ります。                                                                            x
 x                                                                                     x
 x このシステムがダイヤルオンデマンドを使っている場合には、「はい」と答えるべきです。  x
 x インターネットアクセスに常時接続しているのであれば、「いいえ」とすべきです。        x
 x                                                                                     x
 x DNS クエリの数を最小限に留めますか (ダイヤルオンデマンド)?                          x
 x                                                                                     x
 x                        <はい>                          <いいえ>                     x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

受信する気ないのでどっちでも。
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x Exim はローカルに配送された電子メールを異なる形式で格納できます。ほとんどの場合は   x
 x 、mbox と Maildir のどちらかが使われます。mbox はすべてのメールフォルダを           x
 x /var/mail に単一ファイルで格納します。Maildir 形式では、各個のメッセージは          x
 x ~/Maildir/ に分割されたファイルとして格納されます。                                 x
 x                                                                                     x
 x ほとんどのメールツールは、ローカル配送方式が mbox であるとデフォルトでは仮定してい  x
 x ることに注意してください。                                                          x
 x                                                                                     x
 x ローカルメールの配送方式:                                                           x
 x                                                                                     x
 x                         /var/mail/ 内の mbox 形式                                   x
 x                         ホームディレクトリ内の Maildir 形式                         x
 x                                                                                     x
 x                                                                                     x
 x                       <了解>                         <取消>                         x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

金輪際いじる気ないのでいいえ。
 lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu メールサーバの設定: tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
 x                                                                                     x
 x Debian の exim4 パッケージは、1 つのモノリシックなファイルである「単一設定」        x
 x (/etc/exim4/exim4.conf.template) か /etc/exim4/conf.d/ に置かれる約 50 の小さなフ   x
 x ァイルから実際のファイルが構成される「分割設定」のどちらでも利用できます。          x
 x                                                                                     x
 x 単一設定は大きな変更をするのに向いており、一般的により安定しているのに対し、分割設  x
 x 定は小さな変更を行うのに楽な方法を提供します (ただし脆く、配慮せずに変更すると壊れ  x
 x るかもしれません)。                                                                 x
 x                                                                                     x
 x 分割設定と単一設定の詳細な議論については、/usr/share/doc/exim4-base にある Debian   x
 x 固有の README ファイルで参照できます。                                              x
 x                                                                                     x
 x 設定を小さなファイルに分割しますか?                                                 x
 x                                                                                     x
 x                        <はい>                          <いいえ>                     x
 x                                                                                     x
 mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

という感じで設定。
うごいた。

今回はこれであっさり目標は達成できたけど、スマートホスト側でリレー云々の設定が必用な場合もありそうな気がする。
その辺はスマートホスト側のSMTPサーバの設定をどうにかしてください。

FTP接続によるファイル転送のバッチ処理

ftpコマンドでバッチ処理したいときってありますよね。
しょっちゅう同じディレクトリの中身を同じディレクトリに放り込むとか。
じゃ、シェルスクリプト書きましょうということで。
あ、例のごとくWindowsじゃなくてLinuxです

で、今回はFTPS(FTP over SSL)での記述なので、ftpじゃなくてlftp使います。
まあftpでも同じような感じだと思います。

#!/bin/sh

if lftp <<_EOD
set cmd:fail-exit yes
open ftps://ftps.example.com
user hoge hogehoge
cd /remote
lcd /local
mirror -R
quit
_EOD
then
  echo "upload succeeded.n"
else
  echo "upload failed.n"
fi

という感じのシェルスクリプトを今回書きました。
内容としては、lftpコマンドで<<_EODから_EODまでを実行させて、実行結果が正常なら成功したよ、失敗したら失敗したよ、と表示させています。

lftpでは

set cmd:fail-exit yes

とすることで、コマンドが失敗したら接続を切ってエラーを返すようにできます。
バッチ処理にはもってこいです。
そのあと、openで接続先をftpsで開いて、userで認証、cdでリモートのファイルを置きたいディレクトリに移動、lcdでローカルの置きたいファイルがあるディレクトリに移動、mirror -Rでローカルのファイルをリモートにミラーしてquitで終了としてます。
このあたりは人によってやりたいことが違うのでご自由にしましょう。
見ての通り認証のパスワードがめっちゃ記述されている(user hoge hogehogeのhogehogeがパスワード)ので、スクリプトのパーミッションには気をつけましょう。

if – then – else – fiの流れはlftpコマンドが成功したらthenで失敗したらelseってことでまあ詳しくはシェルスクリプトでぐぐってください。

RAID5で不良セクタが発生したときってどうすればいいの?

ディスクを交換しろっていうのが一番正解なのはわかってます。

普通にext3とかext4とかで使ってる場合は

e2fsck -cfy /dev/sda1

とかやれば、e2fsckから間接的にbadblocksが呼び出されて不良セクタのファイルシステムへの登録処理を行ってくれるじゃないですか。
Windowsでいうところのchkdsk /Rみたいなもんですよね。
で、たとえば/dev/sda1と/dev/sdb1と/dev/sdc1でRAID5くんでたとして、/dev/sdc1で不良セクタが発生してmdadmに蹴られてfaultマークつけられたとするじゃないですか。
とりあえずremoveしてRAIDから外しますよね。
で、まあなんか一時的なシステムの不具合だった場合またaddしてやればそのまま動いたり、まあ場合によってはリビルドかけるなりすれば復活するわけじゃないですか。
でも、がちでディスクに問題があるっていうか不良セクタが発生していた場合、とりあえず代替処理してやれば動きそうな気がしてるんですよね。
でも、e2fsckから間接的にbadblocksを呼び出す方法だと、RAID5だとリビルドのRead/Writeが平行して走ることになるから駄目っぽいですよね。
じゃあ直接

badblocks -o badblocks.txt -s /dev/sdc1

とかやって不良セクタの発生してるブロックを書き出してやって、

e2fsck -l badblocks.txt /dev/sdc1

とかやって不良ブロックを不良ブロックinodeに登録って普通のext2/3/4ファイルシステムならできるけど、RAID5アレイ上のファイルシステムだとどう考えても駄目ですよね。
ということはファイルシステムが作成される前の段階で代替処理を行わなければならないわけですが、それってどうやるんでしょうか。
表向きにはHDDの不良セクタの代替処理はファームウェアが勝手にやってくれるとのことなわけですが、実際のところ普通に不良セクタが出没します。
そんなHDDのSMART値をみるとReallocated_Sector_Ctは0だったりします。
全くあてになりません。

で、肝心の代替法なんですが、やっと見つけたと思ったらこんなんでした。

該当ブロックを再配置します

[root@www ~]# dd if=/dev/zero of=/dev/hda3 bs=4096 count=1 seek=120
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 6.4496e-05 seconds, 63.5 MB/s

[root@www ~]# sync

これ本当に再配置ですか?
単に問題の箇所をzeroフィルしてるだけにしか見えないんですけど。

ということでbacblocksで見つけた不良箇所をファイルシステムへ登録せずに、代替セクタ処理を行わせたいんだけどもやり方がわからないわけです。
誰か知らないですか。

mdadmでRAID5構築

LinuxでソフトウェアRAID5をくむならmd使うことになるわけで、作った。
色々と問題があったんだけども。

とりあえず、LVMと組み合わせようかとも思ったけど、組み合わせたところでメリットが見あたらなかったので今回は普通に構築した。

まず、RAID5に利用するパーティションを用意。
今回は1.5Tのパーティションを5つ。
sda3, sdb3, sdd1, sde1, sdf1
である。
パーティションタイプは0xfd(linux RAID auto detect)。
で、

# mdadm --create /dev/md2 --verbose --level=5 --raid-devices=5  /dev/sd[ab]3 /dev/sd[def]1

で最初作ったんだけど、アレイのリビルドが異常におそい。
4M/sくらいとか。
8000分以上とかなめてんの。

[>....................] resync = 1.6% (23715200/1465134592) finish=8221.9min speed=2921K/sec

チャンクサイズの問題だろうと思ったんだけど、まあ一旦構築したアレイのチャンクサイズは変更できないぽい。
ということで、チャンクサイズを指定して作り直す。
細かい容量なんて気にしないでどんと1024指定。

# mdadm -S /dev/md2
# mdadm --create /dev/md2 --verbose --level=5 --raid-devices=5  --chunk=1024 /dev/sd[ab]3 /dev/sd[def]1

当然作り直したらファイルシステムもなくなっていた。
まあ仕方ない。
これでいいだろう、と、様子をみてみると、なぜか一本スペアマークがついている。

md2 : active (auto-read-only) raid5 sdf1[5](S) sde1[3] sdd1[2] sdb3[1] sda3[0]
      5860536320 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [5/4] [UUUU_]

んーと。
とりあえずメタデータを掃除してやろう。

# mdadm -S /dev/md2
mdadm: stopped /dev/md2
# mdadm --misc --zero-superblock /dev/sda3
# mdadm --misc --zero-superblock /dev/sdb3
# mdadm --misc --zero-superblock /dev/sdd1
# mdadm --misc --zero-superblock /dev/sde1
# mdadm --misc --zero-superblock /dev/sdf1
# mdadm --create /dev/md2 --verbose --level=5 --raid-devices=5  --chunk=1024 /dev/sd[ab]3 /dev/sd[def]1

今度はうまくいったようだ。

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active (auto-read-only) raid5 sdf1[4] sde1[3] sdd1[2] sdb3[1] sda3[0]
      5860536320 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [5/5] [UUUUU]
        resync=PENDING

md1 : active raid1 sda1[0] sdb1[1]
      272960 blocks [2/2] [UU]

ということでアレイの情報を/etc/mdadm/mdadm.confに記述する。

# mdadm -Ds | grep md2 >> /etc/mdadm/mdadm.conf

mdadm.confにDEVICEの記述がないなら

DEVICE partitions

とでも記述しておけばいい。
個別に記述しても良いけどめんどくさい。

あとは普通にmke2fsとかしてファイルシステムを作ってfstab書いたりして使えばOK。

リビルドの速度は10倍になった。

[>....................]  resync =  2.4% (36325084/1465134080) finish=557.6min speed=42699K/sec

linux-image-3.0.0-2とlinux-image-2.6.32-5でNFSがうまく動かない

カーネル2.6.32-5でなんかI/O周りでkernel OOPSをはくので、むしゃむしゃしてkernelのバージョンをあげたんですよ。
でね、うちはxen使ってDomUが二つ動いていまして、Dom0はkernel 3.0.0-2で問題なく動いたんだけど、DomUの片方はブートしないでござるの巻きに陥ったわけでして、仕方ないのでそっちは2.6.32で動かしたんですよ。
で、色々と動作確認しているうちに、NFSでマウントしていたディレクトリのオーナーとグループがnobody, nogroupになってることに気づいたわけですよ。
そこから色々と試していくうちにわかったのが、NFSサーバのカーネルが3だと2.6でNFS接続するとnobody, nogroupになるということ。
ああ、ちゃんと共有対象ディレクトリのクライアントとサーバのユーザ名およびuid, グループ名およびgidは同じですよ。
2.6がサーバなら3がクライアントでも2.6がクライアントでも問題なし。
3がサーバの時、クライアントが3なら問題ないけど2.6だとだめ。
オプションでall_squashつけてanonuidとanongid設定しても駄目。
軽く数時間はまりましたよ。
とりあえずカーネルが更新待ちだなー。

追記
やっぱりall_squashとanonuidとanongidでいけました。
うそつきましたごめんなさい。
all_squashで全員nobody, nogroup扱いにして、anonuidとanongidでnobody, nogroupのIDを実際に動作させたいユーザのIDにマッピング。

LVMで割り当てたPVを縮小させたい

2TのHDDのPVを縮小させたい。
ということでメモ。

まずは論理ボリュームの縮小。
論理ボリュームを縮小するときは、ファイルシステムを縮小してから論理ボリュームを縮小する。(拡大するときは逆)

縮小させたい論理ボリュームを縮小。
e2fsck -fyv /dev/ms09/file
resize2fs /dev/ms09/file 16G
lvresize -L 16G /dev/ms09/file
警告でるのでちゃんとサイズがあってるか確認して実行
resize2fs /dev/ms09/file
サイズがあってるか確認

ほかも同じ感じで論理ボリュームの縮小を行う。
システムのルートパーティションの場合はレスキューCDからブートしてやりましょう。

で、PVの縮小。
pvresize –setphysicalvolumesize 500G /dev/sda1
このとき、切り詰めた物理ボリュームの終端よりあとに論理ボリュームっていうかPEがあったりする場合、失敗する。
自動で再配置なんて気の利いたことはしてくれない。
なので、そういう場合は一旦論理ボリュームのバックアップをとって削除してから行うとか、pvmoveで別の物理ボリュームにデータを移してから行わなければならない。

PVが縮小できたらパーティションをPVにあわせて切り直す。
fdiskだと単位がシリンダとかで計算がいやだったのでcfdiskでやった。

パーティション切り直したら再起動して終わり。

MySQLのテーブルの修復

この間久しぶりにCounterize IIの画面を開いた。
全然アクセス数とか気にしなくなっていたので気づくのが遅れたのだけども、いつからかわからないけどもずっとアクセスが0という扱いになっていた。
さすがにアクセス0ということはないので、おそらくデータベースに異常が発生しているんじゃないかと思った。
プラグインの異常ということも考えたけども、ぐぐってみても別にそういう話はヒットしなかったからだ。

で、テーブルの構造とかに間違いがないかを調べていたら、なにやら変なエラーが発生した。
ERROR 145 (HY000)
どういうエラーなのか調べてみたら、どうやらテーブルが破損しているということらしい。
MyISAMテーブルのチェックはmyisamchkでできる。
データベースのデータ格納ディレクトリで

myisamchk -e *.MYI

とかすればチェックできる。
でしらべてみると

Checking MyISAM file: wp_Counterize.MYI
Data records:  267703   Deleted blocks:       0
myisamchk: warning: 9 clients are using or haven't closed the table properly
- check file-size
myisamchk: warning: Size of datafile is: 12830392        Should be: 12830056
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
myisamchk: error: Found 267710 keys of 267703
- check records and index references
myisamchk: error: Record-count is not ok; is 267710       Should be: 267703
myisamchk: warning: Found     267710 parts                Should be: 267703 parts
MyISAM-table 'wp_Counterize.MYI' is corrupted
Fix it using switch "-r" or "-o"

とか出てきた。
そこで、

myisamchk -r wp_Counterize

としたところ、治った模様。

ところで、MySQLさんはテーブルに異常が発生していたら勝手に通知してくれたり修復してくれたりしないのだろうか。
まったくもって気づかなかった。
ログにこっそりはき出されていたりするのかな。
メール通知オプションとかほしいな。
あるのかもしれないけど調べる気もとりあえず今はないでござる。

LVMのスナップショットの動作が怪しい

うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。

# xm pause debian
# lvcreate -s -n snapdebian -L 200G /dev/ms09/debian
  Logical volume "snapdebian" created
# xm unpause debian

としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。

# e2fsck -yfv /dev/ms09/snapdebian
e2fsck 1.41.12 (17-May-2010)
/dev/ms09/snapdebian: recovering journal
Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20)
Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED *****

  715619 inodes used (2.13%)
     738 non-contiguous files (0.1%)
     182 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 706955/133
23572155 blocks used (17.56%)
       0 bad blocks
       6 large files

  677160 regular files
   29784 directories
     126 character device files
      40 block device files
       2 fifos
      16 links
    8469 symbolic links (8324 fast symbolic links)
      29 sockets
--------
  715626 files

マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。

[  647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504
[  647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503
[  647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502
[  647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501
[  647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500
[  647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted
[  647.099710] EXT4-fs (dm-18): recovery complete
[  647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode
[ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds.
[ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.113201] umount        D 0000000000000000     0  4061   2294 0x00000000
[ 1080.113331]  ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8
[ 1080.113544]  0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8
[ 1080.117004]  0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8
[ 1080.117004] Call Trace:
[ 1080.117004]  [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa
[ 1080.117004]  [<ffffffff8100ece2>] ? check_events+0x12/0x20
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe
[ 1080.117004]  [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe
[ 1080.117004]  [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70
[ 1080.117004]  [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77
[ 1080.117004]  [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23
[ 1080.117004]  [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a
[ 1080.117004]  [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70
[ 1080.117004]  [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa
[ 1080.117004]  [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1
[ 1080.117004]  [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a
[ 1080.117004]  [<ffffffff810f226d>] ? deactivate_super+0x60/0x77
[ 1080.117004]  [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b
[ 1080.117004]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b

場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。

この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。

その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。

# lvremove -f /dev/ms09/snapdebian
  Unable to deactivate open ms09-debian-real (254:5)
  Failed to resume debian.

これに関してはバグレポートが見つかった
とりあえず4ヶ月経過しても治っていないらしい。

んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。

あー、設定するのがめんどくさい。