☰

vmwareworkstationのファイルシステムが読み取り専用になる原因は何ですか？

tag-icon • tag-icon linux filesystems virtual-machine vmware vmware-workstation
vmwareworkstationのファイルシステムが読み取り専用になる原因は何ですか？

私はVMware WorkstationでさまざまなバージョンのLinux（ubuntu、debian、Kali）を使用しており、Windows 10をホストとして実行しており、ゲストOSのファイルシステムが断続的に「読み取り専用」になる現象を経験しました。これが起こったようです。 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ディスクは、メカニカルディスクに比べて特別な警告なしに完全にエラーが発生することが多いことに注意してください。

おすすめ記事