O que pode fazer com que o sistema de arquivos seja lido somente na estação de trabalho vmware?

2

Eu tenho usado vários tipos de Linux (Ubuntu, Debian e Kali) no VMware Workstation, executando o Windows 10 como host, e tenho experimentado os sistemas de arquivos do sistema operacional convidado como "somente leitura" de forma intermitente - eu acho aconteceu 2 vezes ontem e hoje.

No começo eu pensei que era apenas uma instalação ruim como estava acontecendo sob o Kali apenas para começar - no entanto, ele começou a afetar o Ubuntu e o Debian também.

Eu executei testes da SMART no lado do Windows e eles não revelam nenhum problema.

Abaixo está o que eu vejo no dmesg após o mais recente reverter para somente leitura:

[    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

Para corrigir isso, estou reiniciando e executando "fsck / dev / sda1 -y" e parece estar bem depois disso, pelo menos por um tempo.

O que pode estar causando esse comportamento, ou há algo mais que eu possa fazer para diagnosticar isso, já que isso está em uma VM e não em uma unidade com capacidade SMART?

Observe também que eu não tive nenhum problema no Windows que indicasse um SSD com falha.

    
por Nick 05.12.2017 / 15:53

1 resposta

1

Como você está suspeitando, o caso mais provável de uma VM ser somente leitura seria um disco defeituoso.

O SMART não é a melhor métrica em um disco de nível de consumidor e, de fato, há evidências comprovadas de vários fabricantes no nível do firmware, e a SMART informando que o disco está sempre em boas condições.

No entanto, a partir dos logs, suspeito que você selecionou o thin provisioning para os discos virtuais do Linux e não tem mais espaço livre em disco / espaço SSD para o disco virtual / sistema de arquivos virtual crescer - portanto, o kernel da VM "inconsistente" - como o provisionamento thin apenas aumenta os discos virtuais conforme necessário.

Lembre-se de que, em vários sistemas operacionais, uma parte do disco é geralmente reservada para manutenção, se você estiver com pouco espaço livre na máquina host.

Se esse não for o caso, eu usaria esse disco como indigno de confiança e começaria a pensar em um substituto. Além disso, lembre-se que os discos SSD geralmente falham completamente sem muitos avisos em comparação com os discos mecânicos.

    
por 05.12.2017 / 16:43