☰

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 디스크는 기계식 디스크에 비해 별다른 경고 없이 완전히 오류가 발생하는 경우가 많다는 점을 명심하세요.

관련 정보