Proxmox VE 踩坑：EXT4-fs error Detected aborted journal，文件系统自动只读

最近PVE宿主机碰到一个挺折磨人的报错，日志长这样：

EXT4-fs error (device dm-1): ext4_journal_check_start:84: comm kworker/u64:2: Detected aborted journal
EXT4-fs (dm-1): Remounting filesystem read-only
ext4_do_writepages: jbd2_start: 1020 pages, ino 5246464; err -30

简单说就是宿主机文件系统被内核自动切到只读模式，没法写入，很多服务直接挂掉。网上翻了不少Proxmox论坛案例，把原理、排查顺序和解决方案整理一下，方便以后自己回看。

日志在说什么

dm-1 在默认PVE安装下，一般对应LVM的根卷，也就是/dev/pve/root，宿主机根目录。

• Detected aborted journal：EXT4的日志（JBD2）被中止了。大多是底层IO异常、磁盘控制器超时、意外断电，导致文件系统日志不一致。
• Remounting filesystem read-only：PVE默认挂载参数errors=remount-ro。内核检测到文件系统风险，自动切换成只读，防止继续写入把数据彻底弄坏，属于保护机制。
• err -30：对应EROFS只读文件系统。这是结果不是根源。文件系统已经只读了，后台写页的kworker进程还尝试写入，才抛出这个错误。

重点：只执行mount -o remount,rw基本没用。journal标记已经中止，不先修复就强行读写，大概率会再次触发只读。

网上同类案例汇总

看了论坛大量同报错帖子，出现这个问题常见就这几种场景：

1. 消费级NVMe电源管理异常

像三星990 PRO、西数SN770这类消费级固态，跑PVE很容易出现。有时就算换了新盘，主板不变依旧复现。
解决：GRUB添加内核参数关闭NVMe电源省电和PCIE ASPM。部分人能解决，但也有人无效，最后换盘或者更换PCIe插槽。

2. PCI直通 / IOMMU 分组冲突

开启虚拟机PCI直通（比如直通HBA、NVMe给TrueNAS等VM）后立刻触发。
原因：直通的控制器和宿主机系统盘控制器在同一个IOMMU组。虚拟机接管控制器后，宿主机直接丢失系统盘，随即触发journal异常。
解决：更换PCI插槽；尽量不要用pcie_acs_override；保证系统盘控制器单独一组。

3. 磁盘固件、内核 / pve-firmware 版本问题

三星980 PRO、金士顿、部分Intel BOSS盘容易踩坑。有时候更新PVE内核或者pve-firmware之后突然爆这个错，SMART看盘体却显示正常。
解决：升级磁盘固件；或者降级内核、pve-firmware到之前稳定版本；也有人直接换成企业级固态解决。

4. 意外断电导致journal损坏

没有硬件报错，断电或者死机重启后，直接进入只读。磁盘本身没坏，只是文件系统日志损坏。
解决：进入救援环境，在未挂载的根卷执行fsck修复；如果journal损坏严重，可重建journal。

5. 磁盘硬件故障

dmesg日志在journal报错之前，出现大量I/O error、Buffer I/O error、nvme timeout、ata frozen。
重点：这种情况不要反复fsck修复！fsck只能修复文件系统元数据，救不了正在坏掉的硬盘。优先备份，然后换盘。

推荐排查顺序

先确认是不是硬件层面问题，再决定修复文件系统，不要上来直接fsck。

1. 查看内核日志

dmesg -T | grep -iE 'EXT4-fs|I/O error|Buffer I/O|nvme|ata|timeout|reset|JBD2|Aborting journal'
journalctl -k -b -1 | grep -iE 'I/O error|nvme|timeout|EXT4'
lsblk -o NAME,SIZE,TYPE,FSTYPE,LABEL,MODEL,MOUNTPOINTS
ls -l /dev/mapper/

看dm-1对应的磁盘设备，重点检查journal报错之前有没有NVMe超时、IO错误、AER报错。

2. 检查磁盘健康状态

替换成你的系统盘设备：

smartctl -a /dev/nvme0
# 或者 SATA盘 smartctl -a /dev/sda

重点看：Media Errors、Critical Warning、重分配扇区、不安全关机次数。

⚠️ 重要提醒：不要在已经挂载的根分区上执行fsck！
要用PVE安装ISO启动进入rescue救援模式，或者其他Linux Live系统操作。

# 激活卷组
vgchange -ay
# 只读预检查，不修改数据
fsck.ext4 -n /dev/pve/root
# 确认分区没有挂载，再修复
umount /dev/pve/root
fsck.ext4 -f -y /dev/pve/root

fsck -y会自动确认修复，严重损坏场景有丢文件风险，有条件先做磁盘镜像备份。

3. 如果是NVMe电源管理导致的报错

修改GRUB内核参数，关闭NVMe省电和PCIE ASPM：

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet nvme_core.default_ps_max_latency_us=0 pcie_aspm=off"

更新引导：

update-grub

如果你的PVE用systemd-boot，则修改cmdline后执行：proxmox-boot-tool refresh

这个方法只是规避消费级NVMe电源休眠bug，不是万能修复方案。

4. PCI直通引发故障处理

检查IOMMU分组。
临时恢复宿主机：进救援模式，把故障虚拟机配置里onboot: 1改为0，删掉错误的hostpci直通配置，再启动。

pcie_acs_override虽然可以拆分IOMMU组，但官方不推荐，风险高，很容易波及系统盘控制器。

5. 重建journal

仅在确认磁盘硬件无IO报错，但是journal反复abort的场景尝试：

fsck -y /dev/pve/root
tune2fs -O ^has_journal /dev/pve/root
fsck -f -y /dev/pve/root
tune2fs -j /dev/pve/root

这一步只是修复文件元数据，如果底层磁盘持续IO报错，重建journal之后依旧会再次触发只读。

快速判断该走哪条路线

1. 报错前存在I/O error/nvme timeout：优先怀疑硬件、固件、链路、IOMMU直通冲突，不要只跑fsck。
2. 更新内核/pve-firmware后立刻出问题，回退旧内核就稳定：固件/驱动问题。
3. 只有意外断电，无底层硬件报错：救援fsck，必要重建journal。
4. 反复触发只读，SMART已经有错误：直接更换系统盘，从备份恢复，不要继续在坏盘硬修。