什么可能导致 vmwareworkstation 下的文件系统变为只读?

什么可能导致 vmwareworkstation 下的文件系统变为只读?

我一直在 VMware Workstation 下使用各种版本的 Linux(ubuntu、debian 和 Kali),运行 Windows 10 作为主机,并且一直遇到来宾操作系统的文件系统间歇性变为“只读”的情况 - 我认为这发生了 2昨天一次,今天一次。

起初我以为这只是一个错误的安装,因为它发生在 Kali 下才开始 - 但后来它也开始影响 Ubuntu 和 Debian。

我已经在 Windows 端运行了 SMART 测试,并且没有发现任何问题。

以下是我最近恢复为只读后在 dmesg 中看到的内容:

[    4.684740] random: crng init done
[    5.357246] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    5.361262] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    5.370915] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    5.371618] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    7.391713] e1000: eth0 NIC Link is Down
[   15.455356] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[  317.358720] EXT4-fs warning (device sda1): ext4_dirent_csum_verify:352: inode #155789: comm updatedb.mlocat: No space for directory leaf checksum. Please run e2fsck -D.
[  317.358722] EXT4-fs error (device sda1): htree_dirblock_to_tree:962: inode #155789: comm updatedb.mlocat: Directory block failed checksum
[  317.358944] Aborting journal on device sda1-8.
[  317.359230] EXT4-fs (sda1): Remounting filesystem read-only
[  317.361153] EXT4-fs warning (device sda1): ext4_dirent_csum_verify:352: inode #155843: comm updatedb.mlocat: No space for directory leaf checksum. Please run e2fsck -D.
[  317.361154] EXT4-fs error (device sda1): htree_dirblock_to_tree:962: inode #155843: comm updatedb.mlocat: Directory block failed checksum
[  317.373714] EXT4-fs warning (device sda1): ext4_dirent_csum_verify:352: inode #154974: comm updatedb.mlocat: No space for directory leaf checksum. Please run e2fsck -D.
[  317.373716] EXT4-fs error (device sda1): htree_dirblock_to_tree:962: inode #154974: comm updatedb.mlocat: Directory block failed checksum

为了解决这个问题,我一直在重新启动并运行“fsck /dev/sda1 -y”,之后似乎就很好了,至少有一段时间了。

可能是什么导致了这种行为,或者考虑到这是在虚拟机中而不是支持 SMART 的驱动器中,我还可以采取其他措施来诊断它吗?

另请注意,我在 Windows 下没有遇到任何表明 SSD 出现故障的问题。

答案1

正如您所怀疑的,虚拟机只读的最可能情况是磁盘损坏。

SMART 并不是消费级磁盘的最佳衡量标准,事实上,有支持证据表明多家制造商在固件级别撒谎,并且 SMART 表示磁盘始终处于良好的运行状况。

但是,从日志中我怀疑您为 Linux 虚拟磁盘选择了精简配置,并且您没有更多的实际磁盘可用空间/SSD 空间来供虚拟磁盘/虚拟文件系统增长 - 因此 VM 内核将其视为“不一致” - 因为精简配置仅根据需要动态增加虚拟磁盘。

请记住,在某些操作系统中,如果主机虚拟机上的可用空间不足,通常会​​保留一部分磁盘用于内务管理。

如果情况并非如此,我会将该磁盘视为不可信,并开始考虑更换。此外,请记住,与机械磁盘相比,SSD 磁盘通常会完全失败,而不会发出太多警告。

相关内容