前情回顾

前段时间使用 Rsync 进行备份时,每次备份到特定位置都会卡住。

还以为磁盘有问题,当时没有去深究。

又一次折腾

昨天对硬盘进行了一次检测, 发现磁盘状态良好。 当然是继续备份啦。

俗话说 “一朝被蛇咬,十年怕井绳”, 这次就没敢再用 Rsync

反正不需要保留文件的各种属性,所以直接 cp 吧。

文件虽然比较多,不过也等了好一会儿, 一切都挺正常的,应该不会再出问题了。

事与愿违

然后就,卡住了 (囧)。

和上次一样的问题, 不过可以肯定硬盘是没有问题的。

那就先看看日志,找到的异常部分如下:

3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#11 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#11 CDB: Write(10) 2a 00 00 78 96 60 00 04 00 00
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#10 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#10 CDB: Write(10) 2a 00 00 78 92 60 00 04 00 00
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#9 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#9 CDB: Write(10) 2a 00 00 78 8e 60 00 04 00 00
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#7 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#7 CDB: Write(10) 2a 00 00 78 8a 60 00 04 00 00
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#3 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
3月 01 22:23:59 pc kernel: sd 3:0:0:0: [sdc] tag#3 CDB: Write(10) 2a 00 00 78 86 60 00 04 00 00
3月 01 22:26:58 pc kernel: INFO: task kworker/u17:2:602 blocked for more than 120 seconds.
3月 01 22:26:58 pc kernel:       Tainted: P           OE     4.20.13-arch1-1-ARCH #1
3月 01 22:26:58 pc kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
3月 01 22:26:58 pc kernel: kworker/u17:2   D    0   602      2 0x80000080
3月 01 22:26:58 pc kernel: Workqueue: kcryptd/254:3 kcryptd_crypt [dm_crypt]
3月 01 22:26:58 pc kernel: Call Trace:
3月 01 22:26:58 pc kernel:  ? __schedule+0x29b/0x8b0
3月 01 22:26:58 pc kernel:  ? _raw_spin_lock_irqsave+0x25/0x50
3月 01 22:26:58 pc kernel:  ? __percpu_counter_sum+0x56/0x60
3月 01 22:26:58 pc kernel:  schedule+0x32/0x90
3月 01 22:26:58 pc kernel:  schedule_preempt_disabled+0x14/0x20
3月 01 22:26:58 pc kernel:  __mutex_lock.isra.1+0x217/0x530
3月 01 22:26:58 pc kernel:  kcryptd_crypt+0x266/0x3a0 [dm_crypt]
3月 01 22:26:58 pc kernel:  process_one_work+0x1eb/0x410
3月 01 22:26:58 pc kernel:  worker_thread+0x2d/0x3d0
3月 01 22:26:58 pc kernel:  ? process_one_work+0x410/0x410
3月 01 22:26:58 pc kernel:  kthread+0x112/0x130
3月 01 22:26:58 pc kernel:  ? kthread_park+0x80/0x80
3月 01 22:26:58 pc kernel:  ret_from_fork+0x35/0x40

尝试解决

看来 cp 进程现在正处于 hang 状态中。

想起以前遇到过的一个问题, 由于 太少,会导致 SDDM 出现 hang。

由于备份盘采用 LUKS 加密,且 随机数生成器 是用的 /dev/random

理所应当的觉得这个问题也是因为熵太少导致的。

当然是抬起我 单身二十几年的右手 啦, 努力的晃动鼠标 (这样可以加快熵的生成)。

晃动了好一会,没有任何的反应。又试着安装了几个 伪随机数生成器 ,没任何用。

求助大佬

还在网络上搜索了好一会儿,也找不出问题所在 (看来提炼关键词的能力还有待提高呀)。

无奈,只能在 #archlinux-cn 群组里向大佬们求助了。

然后提了一个 具有迷惑性的 问题:

cp 时,由于熵太少导致卡住怎么办?
有什么方法可以中途增加熵?

首先给出解决方法的是 @oldherl

晃动鼠标。

这个方法已经试过,没用。

接着 @farseerfs 也给出了解决方法:

执行 find / 以增加熵。

执行之,硬盘真的开始读写了 (迷惑性加剧)

不过一会儿后,问题又依旧。

然后和群里的大佬们就 如何增加熵/为何增加熵会无效/熵到底够不够 等问题分析了好久,依然没有眉目。

直到 @Edward-P 甩出一个链接:

Ubuntu 12.04 LUKS/dmcrypt disk to disk copy freezes

问题终结:

The problem with freezing progress was due to the fact,
that both discs were mounted with 'async' option.
Thus, when the buffer became full,
progress was every time frozen while waiting until the buffer will become empty.

后记

所以提出一个高质量的问题是很重要的。

得再认真的去读一次 《提问的智慧》 了。