我的问题是系统冻结导致破碎的磁盘，也许直接长时间延迟与不正确的configuration（我不知道，直到现在）。
我有10 scsi磁盘没有sctercfunction，并使用mdadm 2 raid6arrays和每个5磁盘，这些磁盘有几个（从几十到几百）Raw_Read_Error_Rate计数，但没有什么严重的。 一般来说，应该没问题，但是一旦对2个arrays进行检查或恢复操作，系统就会挂起。
更多的时候内核恐慌是这样的：
Sep 07 10:30:11 data.srv kernel: INFO: rcu_sched self-detected stall on CPU Sep 07 10:30:11 data.srv kernel: INFO: rcu_sched detected stalls on CPUs/tasks: Sep 07 10:30:11 data.srv kernel: 7-...: (4 GPs behind) idle=9c2/140000000000001/0 softirq=72743/72743 fqs=1170 Sep 07 10:30:11 data.srv kernel: (detected by 2, t=257332 jiffies, g=1192045, c=1192044, q=84877) Sep 07 10:30:11 data.srv kernel: Sending NMI from CPU 2 to CPUs 7: Sep 07 10:30:11 data.srv kernel: NMI backtrace for cpu 7 Sep 07 10:30:11 data.srv kernel: CPU: 7 PID: 7112 Comm: md125_raid6 Tainted: GI 4.12.8-gentoo #2 Sep 07 10:30:11 data.srv kernel: Hardware name: Dell Inc. PowerEdge R510/084YMW, BIOS 1.12.0 07/26/2013 Sep 07 10:30:11 data.srv kernel: task: ffff880613b34500 task.stack: ffffc900089d0000 Sep 07 10:30:11 data.srv kernel: RIP: 0010:cfb_imageblit+0x48d/0x4d0 Sep 07 10:30:11 data.srv kernel: RSP: 0018:ffff880617cc3a98 EFLAGS: 00000086 Sep 07 10:30:11 data.srv kernel: RAX: 00000000ff000000 RBX: ffff8806123b9cc1 RCX: 0000000000000007 Sep 07 10:30:11 data.srv kernel: RDX: ffffc90006edf040 RSI: 00000000ff000000 RDI: 0000000000000001 Sep 07 10:30:11 data.srv kernel: RBP: ffffc90006edf044 R08: ffffffff81aaa900 R09: 0000000000aaaaaa Sep 07 10:30:11 data.srv kernel: R10: 0000000000000000 R11: 0000000000000001 R12: ffffc90006edf0c0 Sep 07 10:30:11 data.srv kernel: R13: 0000000000000220 R14: 000000000000000b R15: ffffc90006edeea0 Sep 07 10:30:11 data.srv kernel: FS: 0000000000000000(0000) GS:ffff880617cc0000(0000) knlGS:0000000000000000 Sep 07 10:30:11 data.srv kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Sep 07 10:30:11 data.srv kernel: CR2: 00007f81e893d400 CR3: 0000000006409000 CR4: 00000000000006e0 Sep 07 10:30:11 data.srv kernel: Call Trace: Sep 07 10:30:11 data.srv kernel: <IRQ> Sep 07 10:30:11 data.srv kernel: ? fbcon_putcs+0xf3/0x130 Sep 07 10:30:11 data.srv kernel: ? bit_putcs+0x2a4/0x480 Sep 07 10:30:11 data.srv kernel: ? soft_cursor+0x18e/0x200 Sep 07 10:30:11 data.srv kernel: ? bit_clear+0xf0/0xf0 Sep 07 10:30:11 data.srv kernel: ? fbcon_putcs+0xf3/0x130 Sep 07 10:30:11 data.srv kernel: ? fbcon_redraw.isra.31+0xdc/0x1c0 Sep 07 10:30:11 data.srv kernel: ? fbcon_scroll+0xfe/0xd30 Sep 07 10:30:11 data.srv kernel: ? con_scroll+0x156/0x170 Sep 07 10:30:11 data.srv kernel: ? lf+0x79/0x80 Sep 07 10:30:11 data.srv kernel: ? vt_console_print+0x283/0x3b0 Sep 07 10:30:11 data.srv kernel: ? console_unlock+0x3bc/0x4a0 Sep 07 10:30:11 data.srv kernel: ? vprintk_emit+0x227/0x2e0 Sep 07 10:30:11 data.srv kernel: ? printk+0x3e/0x46 Sep 07 10:30:11 data.srv kernel: ? task_tick_fair+0x5a8/0x660 Sep 07 10:30:11 data.srv kernel: ? rcu_check_callbacks+0x495/0x840 Sep 07 10:30:11 data.srv kernel: ? tick_sched_do_timer+0x40/0x40 Sep 07 10:30:11 data.srv kernel: ? update_process_times+0x23/0x50 Sep 07 10:30:11 data.srv kernel: ? tick_sched_handle.isra.15+0x29/0x40 Sep 07 10:30:11 data.srv kernel: ? tick_sched_timer+0x33/0x60 Sep 07 10:30:11 data.srv kernel: ? __hrtimer_run_queues+0xc1/0x200 Sep 07 10:30:11 data.srv kernel: ? hrtimer_interrupt+0x9d/0x1e0 Sep 07 10:30:11 data.srv kernel: ? smp_apic_timer_interrupt+0x2f/0x40 Sep 07 10:30:11 data.srv kernel: ? apic_timer_interrupt+0x7f/0x90 Sep 07 10:30:11 data.srv kernel: </IRQ> Sep 07 10:30:11 data.srv kernel: ? _raw_spin_unlock_irqrestore+0x5/0x10 Sep 07 10:30:11 data.srv kernel: ? mddev_unlock+0x81/0xd0 Sep 07 10:30:11 data.srv kernel: ? raid5d+0x40/0x5c0 起初，我怀疑沉重的Io负载和Io延迟破坏的磁盘导致软locking，所以我试图限制数组的sync_speed_max，并设置一个较低的磁盘超时（/ sys / block / sd？/ device /超时），并根据这里的描述存储超时如何工作，以及何时他们是一个因素？ ，因为我使用raid6，我相信这是足够安全的。
但是说这样做只是使系统不太“软弱”，而且还很弱，可能不会太快冻结。
然后我怀疑在内核中有一些不正确的设置，因为内核似乎太敏感了，所以我改变了一些可能相关的设置，并且将内核从4.12.8更新到4.13.0（更具体地说，gentoo-源 – 4.13.0，因为我使用的是Gentoo）。 这些是一些关键的变化：
DETECT_HUNG_TASK n -> y LOCKUP_DETECTOR n -> y PANIC_TIMEOUT 0 -> 16 WQ_WATCHDOG n -> y DM_DELAY n -> m IOSCHED_BFQ n -> m RCU_EXPERT n -> y SENSORS_I5500 n -> m
好吧！ 事情似乎现在好了！ 即使在更多的io压力下，raid6arrays重build和检查不会使系统冻结或挂起！
但是我不确定哪个是正确的，可能是内核更新或LOCKUP_DETECTOR，我不知道，也许有人可以帮助我！
当我发现这个问题，“mdadm resync freeze system”是一个很普遍的问题，也许我的经验可以帮助像我这样的其他人！
一些系统信息：
mdadm - v4.0 - 2017-01-09 Linux data.srv 4.13.0-gentoo #2 SMP Thu Sep 7 20:02:26 +08 2017 x86_64 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz GenuineIntel GNU/Linux