前情回顧

前段時間使用 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.

後記

所以提出一個高質量的問題是很重要的。

得再認真的去讀一次 《提問的智慧》 了。