環境
- 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 すらできなくなる。
nfs のマウントには soft と hard の二種類があって、soft は NFS サーバが応答しなくなった時にエラーを返すらしい。
でも帰ってきたエラーをアプリケーション側が上手くハンドルしないとファイル壊れちゃうので hard が推奨。
hard はサーバが応答しなくなっても待ち続ける。soft のようにファイルが壊れることもないらしいし、一時的にサーバが落ちても大丈夫なのでNFSサーバの再起動とかしても問題無い。
けれど待ち続けてる間で kernel task が 120 秒とかを越えると kernel panic しちゃうみたい。
hard を付けた状態で panic するんじゃなくて kernel が task を止められるように intr を付けておくと panic しなくなった。
設定後4ヶ月くらい様子を見ているけれど再現はしていないっぽい。
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 も一緒に付けておいた方が良さそう。
