Внешний привод висит, нагрузка средняя через крышу

У меня есть внешний USB-накопитель, и я запускаю почасовую rsync для него в качестве резервной копии. Это работало хорошо в течение многих лет. На этих выходных я получил два новых внутренних накопителя емкостью 2 ТБ и решил, что пришло время переустановить Ubuntu с нуля, чтобы очистить весь старый хлам.

Примерно один раз в день после переустановки скрипт резервного копирования сильно зависает, обычно в «rm -rf», который я делаю до rsync. К тому времени, когда я замечаю проблему, моя средняя нагрузка находится в стратосфере и быстро поднимается (один раз это было больше 150), но все, что не касается диска, кажется, работает нормально. Одной вещью, которую я нахожу подозрительной, является то, что что-то, я не знаю, что делает команду «smartctl» и «hdparm» на USB-накопителе. Я почти уверен, что smartctl не должен работать на внешних дисках. Я не могу понять, что делает это, либо. Вот часть ps auwwfx, когда она зависла:

root      7310  0.0  0.0   4248   352 ?        D    20:15   0:00 /sbin/hdparm -C /dev/sdd
root      7808  0.0  0.0  17372  1632 ?        D    20:15   0:00 /usr/sbin/smartctl -a -n standby -A -i /dev/sdd
(repeated every 5 minutes between the time the drive hung and now)

Почему это происходит и как я могу это остановить?

обновление Оказывается, это плагин munin "hddtemp_smartctl", который выполняет эти две команды, но они работают большую часть дня, а затем внезапно начинают зависать. Так что я не ближе к ответу.

обновление Я также нашел это в kern.log в последний раз, когда это произошло:

Sep 21 23:18:01 allhats2 kernel: [52652.707110] INFO: task kjournald:4380 blocked for more than 120 seconds.
Sep 21 23:18:01 allhats2 kernel: [52652.707113] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 21 23:18:01 allhats2 kernel: [52652.707114] kjournald       D ffffffff81806200     0  4380      2 0x00000000
Sep 21 23:18:01 allhats2 kernel: [52652.707117]  ffff8803661e1c10 0000000000000046 ffff8803fd890148 ffff880404f17000
Sep 21 23:18:01 allhats2 kernel: [52652.707120]  ffff8803661e1fd8 ffff8803661e1fd8 ffff8803661e1fd8 00000000000137c0
Sep 21 23:18:01 allhats2 kernel: [52652.707122]  ffff880404e89700 ffff880361304500 ffff8803661e1bf0 ffff88041f5d4080
Sep 21 23:18:01 allhats2 kernel: [52652.707125] Call Trace:
Sep 21 23:18:01 allhats2 kernel: [52652.707130]  [<ffffffff811a8a40>] ? __wait_on_buffer+0x30/0x30
Sep 21 23:18:01 allhats2 kernel: [52652.707133]  [<ffffffff8165850f>] schedule+0x3f/0x60
Sep 21 23:18:01 allhats2 kernel: [52652.707135]  [<ffffffff816585bf>] io_schedule+0x8f/0xd0
Sep 21 23:18:01 allhats2 kernel: [52652.707137]  [<ffffffff811a8a4e>] sleep_on_buffer+0xe/0x20
Sep 21 23:18:01 allhats2 kernel: [52652.707139]  [<ffffffff81658ddf>] __wait_on_bit+0x5f/0x90
Sep 21 23:18:01 allhats2 kernel: [52652.707140]  [<ffffffff811a8a40>] ? __wait_on_buffer+0x30/0x30
Sep 21 23:18:01 allhats2 kernel: [52652.707142]  [<ffffffff81658e8c>] out_of_line_wait_on_bit+0x7c/0x90
Sep 21 23:18:01 allhats2 kernel: [52652.707145]  [<ffffffff8108ab20>] ? autoremove_wake_function+0x40/0x40
Sep 21 23:18:01 allhats2 kernel: [52652.707146]  [<ffffffff811a8a3e>] __wait_on_buffer+0x2e/0x30
Sep 21 23:18:01 allhats2 kernel: [52652.707149]  [<ffffffff81257534>] journal_commit_transaction+0x484/0xfc0
Sep 21 23:18:01 allhats2 kernel: [52652.707152]  [<ffffffff8125b5eb>] kjournald+0xeb/0x250
Sep 21 23:18:01 allhats2 kernel: [52652.707154]  [<ffffffff8108aae0>] ? add_wait_queue+0x60/0x60
Sep 21 23:18:01 allhats2 kernel: [52652.707155]  [<ffffffff8125b500>] ? commit_timeout+0x10/0x10
Sep 21 23:18:01 allhats2 kernel: [52652.707157]  [<ffffffff8108a03c>] kthread+0x8c/0xa0
Sep 21 23:18:01 allhats2 kernel: [52652.707160]  [<ffffffff81664b74>] kernel_thread_helper+0x4/0x10
Sep 21 23:18:01 allhats2 kernel: [52652.707162]  [<ffffffff81089fb0>] ? flush_kthread_worker+0xa0/0xa0
Sep 21 23:18:01 allhats2 kernel: [52652.707163]  [<ffffffff81664b70>] ? gs_change+0x13/0x13