WSL генерирует сотни сообщений с hv_storvsc... в секунду.

У меня Ubuntu 22.04.3 в WSL. Каждую секунду в лог записывается около 100 сообщений, подобных этому:

[   88.455305] hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#12 cmd 0x28 status: scsi 0x2 srb 0x4 hv 0xc0000001

$ sudo dmesg -C ; sleep 10; dmesg | grep hv_storvsc | wc -l
1114

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

Что я пробовал:

• Переустановить дистрибутив с нуля
• Переустановить WSL (отключить функцию в Windows, перезагрузить)
• wsl --update – у меня версия 2.2.4
• Переустановить Windows 10 с нуля
• Проверить диск на ошибки как в Windows, так и в Linux. Ошибок нет.
• Повторил поведение на новом, только что распакованном оборудовании.

Кто-нибудь имеет предложения о том, как решить эту проблему?

Не предполагая ваш уровень навыков, это для всех, кто столкнется с ответом: Убедитесь, что вы понимаете, что делаете. ВЫ МОЖЕТЕ ВЕРЯКОННЫМ ОБРАЗОМ НАНЕСТИ ВРЕД ВАШИМ WSL И WINDOWS ФАЙЛОВЫМ СИСТЕМАМ, НЕНАВИДЯ sudo КОМАНДЫ НА ДИСКАХ

Эта тема предлагает запустить проверку диска на вашем диске через Windows:

У меня была такая же проблема, и использование SSD-диска также было 100% в диспетчере задач. Оказалось, что есть ошибки плохих секторов на диске хоста. Это также было исправлено с помощью проверки диска (диск C) на хосте Windows с правами администратора + перезагрузка chkdsk C: /f /r /x

В этом случае пользователь работает на своем диске C из Windows, /f блокирует и исправляет диск. /r находит плохие сектора и восстанавливает информацию поверх того, что делает /f. /x принуждает предварительно размонтировать диск и также выполняет то, что делает /f. Возможно, вы можете пропустить опцию /f. Смотрите здесь для получения дополнительной информации.

Эта тема также намекает на необходимость использования e2fsck из wsl после исправления стороны Windows, но инструкции могут быть потенциально более опасными, так как пользователь не указывает на необходимость размонтирования диска сначала (что требуется для e2fsck, если вы не эксперт). Я, вероятно, сначала попробую решение для Windows и посмотрю, достаточно ли этого.

а затем, когда я загрузил дистрибутив Ubuntu, корневая файловая система была смонтирована в режиме только для чтения из-за ошибок файловой системы, подтвержденных с помощью sudo e2fsck /dev/sdd -p

Здесь пользователь просит e2fsck автоматически исправить части файловой системы, которые он может. Я предполагаю, что пользователь получил ошибку, пытаясь выполнить этот шаг, указывающую на то, что она была смонтирована/только для чтения и не могла быть выполнена.

Мне пришлось восстановить файловую систему с помощью sudo e2fsck /dev/sdd -y

Это потенциально опасно, пользователь просит e2fsck исправить файловую систему с правами суперпользователя и предполагает ‘да’ в ответ на все вопросы. Опять же, диск должен быть размонтирован для этого. Я, вероятно, проведу намного больше исследований, прежде чем пытаться этот шаг самостоятельно.

Очевидно, вам также потребуется заменить пути к дискам на те, которые соответствуют вашей системе.

Пример того, что я вижу на Windows 11 с WSL Ubuntu 22.04.3:

$ sudo dmesg | grep storvsc
[    0.324754] hv_vmbus: registering driver hv_storvsc
[    0.326620] scsi host0: storvsc_host_t
[    3.438044] hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#831 cmd 0x2a status: scsi 0x0 srb 0x4 hv 0xc00000a1

Это оказался баг в HyperV. Это происходит только после гибернации и с ядрами новее 5.5, так как определенная функция была включена в 5.5.

Решение: установить более старое ядро или более новое ядро с отключенной этой функцией.

Для получения дополнительной информации я рекомендую прочитать этот комментарий в вопросе Github, а также эту тему для соответствующего ядра, которое исправит проблему, а также инструкции по установке ядра.

Я вернулся к версии 5.4.0, которая работает безупречно.