ラベル NFS の投稿を表示しています。 すべての投稿を表示
ラベル NFS の投稿を表示しています。 すべての投稿を表示

2016/12/21

qcow2 の cluster leak を直す

qcow2 の cluster leak を直してみたログ。
オチがついてて原因が完全特定できていないのでふわっとしたお話。


環境

Host OS: CentOS 7.1.1503
Host Kernel: 3.10.0-327.4.5.el7.x86_64
qemu-img: 1.5.3


状況

VMイメージ を GFS2 上に置いているVMで ls が返ってこない。
pcs から見る限り clvmd も dlm も全ノード上で動いているし全ノード online になっている。
過去にクラスタの1ノードが物理的な問題で急に落ちたこともあって VM イメージの破損を疑ってみる。
調べてみると qcow2 の整合性の確認には qemu-img の check コマンドを使うことができるらしい。

qemu-img check を qcow2 に対して打つとこんな結果が返ってくる。
[root@hoge ~]# qemu-img check /mnt/hoge/fuga.qcow2
Leaked cluster 42362 refcount=1 reference=0
Leaked cluster 42363 refcount=1 reference=0
Leaked cluster 42364 refcount=1 reference=0
Leaked cluster 42365 refcount=1 reference=0
4 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
65043/524288 = 12.41% allocated, 0.15% fragmented, 0.00% compressed clusters
Image end offset: 4264099840
何やらエラーが返ってきている。
同じ GFS2 の上にある VM に対しても qemu-img check すると
[root@hoge ~]# qemu-img check /mnt/hoge/piyo.qcow2
No errors were found on the image.
468877/524288 = 89.43% allocated, 0.13% fragmented, 0.00% compressed clusters
Image end offset: 30733303808
と返すので問題の VM のみがエラーを吐いているらしい。


解決方法

qemu-img check -h を読んでいると -r オプションがあって、リカバリを試すことができる様子。
Parameters to check subcommand:
  '-r' tries to repair any inconsistencies that are found during the check.
       '-r leaks' repairs only cluster leaks, whereas '-r all' fixes all
       kinds of errors, with a higher risk of choosing the wrong fix or
       hiding corruption that has already occurred.
今回は cluster leak のようなので qemu-img -check r leaks を実行してみた。
どうやら上手くいったようで check してもエラーを返さなくなった。
直したイメージを起動すると ls が返ってきたのでめでたしめでたし。


オチ

これで直ったと思っていたらlsを返さない他のVMを発見。
そしてこいつは qemu-img check でエラーを返さない。
修復した VM の /var/log/messages に、 nfs への書き込みが time out している kernel panic っぽいものを発見。
両方のVMは同じ nfs をマウントしてたので nfs が原因説が濃厚に。
ちなみにある時間から nfs head server がレスポンスを返さない状態になっていたらしい。
おそらく前にもあった案件と同じ原因では無いかと思ってます。
しかし若干の謎があって、nfsをマウントしていたVMは最低限3つある上2つは死んでいたのに1つだけは生きていた。
しかも生きていたVMの mount option に intr は無い。
生きてたVMは書き込していなかった、とすれば辻褄はあうのですがそれはログからは分からなかった。

nfs server 側は私が直接触っていないので余計曖昧な情報ですが、レスポンスを返さない原因は特定のパーティションの容量が一杯だったせいとか。
容量一杯で nfs への書き込みができないのはともかく、それでハングするものなのだろうか。
最終的な対応としては nfs server 側の容量を空けることでおしまい。


ということで qcow2 の cluster leak を直したものの、本来の原因では無かった可能性がある。

2016/04/30

NFS と intr オプション

CentOS 7 で NFS を mount しているとたまに kernel がハングする時があったのでそのログとか対処法とか。


環境


  • CentOS : 7.1.1503
  • kernel : 3.10.0-327.4.5.el7.x86_64 (だったと思う)
  • nfs-utils : 1.3.0-0.21.el7.x86_64


状況

/var/log/messages を見ると
hogehoge kernel: nfs: server 10.20.30.40 not responding, still tryinghogehoge kernel: nfs: server 10.20.30.40 not responding, timed out
とか出てる。どうやら nfs までのネットワークか nfs 本体が不安定な時があるらしい。

最悪の場合のログがこれ。 ssh すらできなくなる。
INFO: task kworker/u289:1:113889 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u289:1  D ffff885eff613680     0 113889      2 0x00000080
Workqueue: writeback bdi_writeback_workfn (flush-0:36)
ffff885c819e7c88 0000000000000046 ffff885e59db0000 ffff885c819e7fd8
ffff885c819e7fd8 ffff885c819e7fd8 ffff885e59db0000 ffff885ca53efd90
ffff88607ff66220 0000000000000080 0000000000000000 ffff885e64f15268
Call Trace:
[<ffffffff816098d9>] schedule+0x29/0x70
[<ffffffff811f066a>] inode_sleep_on_writeback+0x9a/0xd0
[<ffffffff81098240>] ? wake_up_bit+0x30/0x30
[<ffffffff811f1aa0>] wb_writeback+0x170/0x2f0
[<ffffffff811f31cb>] bdi_writeback_workfn+0x2cb/0x460
[<ffffffff8108f0cb>] process_one_work+0x17b/0x470
[<ffffffff8108fe9b>] worker_thread+0x11b/0x400
[<ffffffff8108fd80>] ? rescuer_thread+0x400/0x400
[<ffffffff8109727f>] kthread+0xcf/0xe0
[<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
[<ffffffff81614358>] ret_from_fork+0x58/0x90
[<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
INFO: task scp:114899 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
scp             D ffff885eff533680     0 114899      1 0x00000080
ffff885d75dafb78 0000000000000082 ffff88bce8d14fa0 ffff885d75daffd8
ffff885d75daffd8 ffff885d75daffd8 ffff88bce8d14fa0 ffff885eff533f48
ffff88607ff624e8 0000000000000002 ffffffff811562e0 ffff885d75dafbf0
Call Trace:
[<ffffffff811562e0>] ? wait_on_page_read+0x60/0x60
[<ffffffff81609bdd>] io_schedule+0x9d/0x130
[<ffffffff811562ee>] sleep_on_page+0xe/0x20
[<ffffffff816079b0>] __wait_on_bit+0x60/0x90
[<ffffffff81156076>] wait_on_page_bit+0x86/0xb0
[<ffffffff81098280>] ? autoremove_wake_function+0x40/0x40
[<ffffffff811561b1>] filemap_fdatawait_range+0x111/0x1b0
[<ffffffff81156277>] filemap_fdatawait+0x27/0x30
[<ffffffff811f0568>] __writeback_single_inode+0x1b8/0x220
[<ffffffff811f1467>] writeback_single_inode+0xe7/0x1b0
[<ffffffff811f156e>] sync_inode+0x3e/0x60
[<ffffffffa06ea1bc>] nfs_wb_all+0x5c/0x100 [nfs]
[<ffffffffa06df410>] nfs_setattr+0x1e0/0x1f0 [nfs]
[<ffffffff811e3739>] notify_change+0x279/0x3d0
[<ffffffff811c4b13>] do_truncate+0x73/0xc0
[<ffffffff811c9168>] ? __sb_start_write+0x58/0x110
[<ffffffff811c4ea4>] do_sys_ftruncate.constprop.17+0x114/0x170
[<ffffffff811c4f3e>] SyS_ftruncate+0xe/0x10
[<ffffffff81614409>] system_call_fastpath+0x16/0x1b
/home を nfs の上に置いてるからかもしれないけれど何もできなくなるので、だいたい再起動することになる。
負荷が高い時に発生するのかと思って再現させようとしても耐える時は耐える。
特に私が見てない時に他の人が使って止まってしまったことがほとんどなので、原因も対処方も若干憶測が入ってるのがちょっとつらい。


対処

クライアント側で intr オプション付けると良さそう。 mount コマンドなら
$ mount --verbose -t nfs -o intr 10.20.30.40:/path/to/mount-target /path/to/mount-point
とか。 /etc/fstab だと hard/soft の部分を hard,intr にする。
nfs のマウントには soft と hard の二種類があって、soft は NFS サーバが応答しなくなった時にエラーを返すらしい。
でも帰ってきたエラーをアプリケーション側が上手くハンドルしないとファイル壊れちゃうので hard が推奨。
hard はサーバが応答しなくなっても待ち続ける。soft のようにファイルが壊れることもないらしいし、一時的にサーバが落ちても大丈夫なのでNFSサーバの再起動とかしても問題無い。
けれど待ち続けてる間で kernel task が 120 秒とかを越えると kernel panic しちゃうみたい。
hard を付けた状態で panic するんじゃなくて kernel が task を止められるように intr を付けておくと panic しなくなった。
設定後4ヶ月くらい様子を見ているけれど再現はしていないっぽい。


まとめ

NFS の mount option に hard を指定する場合は intr も一緒に付けておいた方が良さそう。


参考