遇到这种日志疯狂刷屏把系统拖垮的情况真的太糟心了！看你已经试过重装发行版、WSL、甚至整个Windows，换了新硬件也没解决，那我来分享几个针对性的排查和解决思路：

一、先临时救急：压低日志输出级别 #

先把疯狂输出的日志给压下去，让系统先恢复可用状态。你可以通过调整内核日志级别来过滤掉这类低优先级的日志：

• 临时生效（重启WSL后失效）：

  echo 3 | sudo tee /proc/sys/kernel/printk
  

  这个命令把控制台日志级别设为3，只会显示警告及以上级别的日志，那些hv_storvsc的信息日志就不会疯狂输出了。
• 持久化生效：
  编辑/etc/sysctl.conf文件，添加一行：

  kernel.printk = 3 4 1 7
  

  然后执行sudo sysctl -p让配置立刻生效，这样每次启动WSL都会自动应用这个日志级别。

二、排查WSL存储挂载相关设置 #

hv_storvsc是Hyper-V的存储虚拟化驱动，问题大概率出在WSL和Windows的存储交互上：

• 试试关闭WSL的自动挂载功能：编辑/etc/wsl.conf文件（如果没有就新建），添加以下内容：

  [automount]
  enabled = false
  

  然后执行wsl --shutdown重启WSL，看看日志是否还会疯狂输出。注意这样会导致Windows的文件系统无法直接在WSL里访问，如果需要的话可以手动挂载，但先用来排查问题。
• 检查自定义挂载选项：如果你在/etc/fstab里配置了额外的挂载参数，比如针对Windows磁盘的挂载，试试暂时注释掉这些配置，重启WSL后观察日志情况。

三、尝试切换到WSL 1版本测试 #

WSL 1和WSL 2的虚拟化实现完全不同，WSL 1不会依赖Hyper-V的存储驱动，你可以试试切换版本看看问题是否消失：

wsl --set-version Ubuntu-22.04 1

切换完成后重启WSL，用你之前的命令sudo dmesg -C ; sleep 10; dmesg | grep hv_storvsc | wc -l测试日志数量。如果问题消失，说明是WSL 2的Hyper-V存储驱动存在bug，你可以暂时用WSL 1过渡，或者等待官方修复。

四、向官方反馈问题 #

既然你在全新硬件上也能复现这个问题，说明这很可能是WSL或者Windows的官方bug。建议：

• 在Windows反馈中心提交详细反馈，附上你的WSL版本（2.2.4）、Windows版本、Ubuntu版本，以及dmesg的日志片段。
• 去GitHub的WSL官方仓库提交Issue，描述清楚你的复现步骤和已尝试的解决方案，帮助官方更快定位修复。

备注：内容来源于stack exchange，提问作者vidarlo