Question

显然存在XFS锁定内核/进程并在流量大的情况下破坏卷的已知问题。一些网页谈论它，但我无法弄清楚哪些页面是新的并且可能有解决方案。

我公司的Debian部署有内核3.4.107，xfsprogs 3.1.4和大型存储阵列。我们使用异步IO到几个大容量的大数据（PB）和高吞吐量（GB /秒）。我们经常在几个系统上遇到这些不可预测的锁定。内核日志/ dmesg显示如下内容：

2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986515] INFO: task Sr2dReceiver-5:46829 blocked for more than 120 seconds.
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986518] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986520] Sr2dReceiver-5  D ffffffff8105b39e     0 46829   7284 0x00000000
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986524]  ffff881e71f57b38 0000000000000082 000000000000000b ffff884066763180
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986529]  0000000000000000 ffff884066763180 0000000000011180 0000000000011180
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986532]  ffff881e71f57fd8 ffff881e71f56000 0000000000011180 ffff881e71f56000
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986536] Call Trace:
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986545]  [<ffffffff814ffe9f>] schedule+0x64/0x66
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986548]  [<ffffffff815005f3>] rwsem_down_failed_common+0xdb/0x10d
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986551]  [<ffffffff81500638>] rwsem_down_write_failed+0x13/0x15
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986555]  [<ffffffff8126b583>] call_rwsem_down_write_failed+0x13/0x20
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986558]  [<ffffffff814ff320>] ? down_write+0x25/0x27
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986572]  [<ffffffffa01f29e0>] xfs_ilock+0xbc/0x12e [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986580]  [<ffffffffa01eec71>] xfs_rw_ilock+0x2c/0x33 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986586]  [<ffffffffa01eec71>] ? xfs_rw_ilock+0x2c/0x33 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986593]  [<ffffffffa01ef234>] xfs_file_aio_write_checks+0x41/0xfe [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986600]  [<ffffffffa01ef358>] xfs_file_buffered_aio_write+0x67/0x179 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986603]  [<ffffffff8150099a>] ? _raw_spin_unlock_irqrestore+0x30/0x3d
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986611]  [<ffffffffa01ef81d>] xfs_file_aio_write+0x163/0x1b5 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986614]  [<ffffffff8106f1af>] ? futex_wait+0x22c/0x244
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986619]  [<ffffffff8110038e>] do_sync_write+0xd9/0x116
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986622]  [<ffffffff8150095f>] ? _raw_spin_unlock+0x26/0x31
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986634]  [<ffffffff8106f2f1>] ? futex_wake+0xe8/0xfa
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986637]  [<ffffffff81100d1d>] vfs_write+0xae/0x10a
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986639]  [<ffffffff811015b3>] ? fget_light+0xb0/0xbf
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986642]  [<ffffffff81100dd3>] sys_pwrite64+0x5a/0x79
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986645]  [<ffffffff81506912>] system_call_fastpath+0x16/0x1b

锁定会使系统处于不良状态。处于D状态的进程甚至不能用信号9杀死。恢复操作的唯一方法是重新启动，修复XFS，然后系统再工作。但偶尔在锁定之后我们甚至无法修复一些卷，因为它们完全损坏了，我们需要用mkfs重建它们。

作为最后的手段，我们现在定期运行xfs-repair，这在一定程度上减少了锁定和数据丢失的频率。但事件仍然经常发生，所以我们需要一些解决方案。

我想知道是否有内核3.4.107的解决方案，例如我们可能会申请一些补丁。由于大量的部署和其他软件问题，我们无法在不久的将来升级内核。

但是，我们正在努力更新我们的应用程序，以便我们可以在下一版本中运行内核3.16。有谁知道这个XFS锁定问题是否在3.16中修复了？

Answer 1

有些人已经体验过这一点，但这不是XFS的问题，因为内核无法在120秒的时间内刷新脏页。看看这里，但请检查他们在您自己的系统上默认使用的数字。

http://blog.ronnyegner-consulting.de/2011/10/13/info-task-blocked-for-more-than-120-seconds/

在这里

http://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/

您可以通过运行此

来查看您的脏缓存比率

sysctl -a | grep dirty

或

cat /proc/sys/vm/dirty_ratio

我能找到的关于此的最佳记录就在这里......

https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

基本上，您需要调整应用程序以确保它可以在该时间段内将脏缓冲区写入磁盘或更改计时器周期等。

您还可以看到一些有趣的参数如下

sysctl -a | grep hung

您可以使用/etc/sysctl.conf永久增加超时，如下所示......

kernel.hung_task_timeout_secs = 300

Answer 2

有人知道这个XFS锁定问题是否在3.16中得到修复？

A Short Guide to Kernel Debugging：

这样说

搜索“xfs splice deadlock”会显示2011年的电子邮件主题，其中描述了这一点问题。但是，将内核源存储库二等分显示出来直到2014年4月（8d02076）才在Linux 3.16中发布该错误。

Linux中的XFS锁定是否有任何解决方案？

2 个答案: