O mesmo disco ext4 pode ser montado a partir de dois hosts, um somente leitura?

Eu sei que montar o mesmo disco com um sistema de arquivos ext4 de dois servidores diferentes (é um vloume iSCSI) provavelmente corromperá os dados no disco. Minha pergunta é : fará alguma diferença se um dos servidores monta o disco somente leitura enquanto o outro monta a leitura / gravação?

Sei que o OCFS2 ou os gostos poderiam ser usados para isso e que eu poderia exportar o disco com o NFS para ser acessível ao outro servidor, mas gostaria de saber se a instalação que proponho funcionará.

linux mount ext4

— Fernando
fonte

Só poderia funcionar se ambos montassem somente leitura (e com isso quero dizer verdadeiro somente leitura que não escreve). Assim que um lado monta a leitura e gravação, o outro lado (somente leitura montado) não espera alterações do outro lado (leitura e gravação montada) e, portanto, lê dados corrompidos. O que você precisa é de um sistema de arquivos com reconhecimento de cluster ou de um servidor único que exponha um sistema de arquivos de rede ao outro.

— Frostschutz 22/03

@frostschutz Sim, ambos os ro funcionarão, mas não sem truques, já que o ro-mount do ext4 grava no disco real (precisa de um loop ro e de um overlayfs cada).

— Ned64 18/09

Compartilharei um caso de uso aqui: um servidor físico e um servidor virtual estão compartilhando um disco físico com passagem de disco. O servidor virtual está montando o disco como rw. Gostaria de copiar uma grande quantidade de dados do disco, mas a rede está muito lenta. Seria ótimo se eu pudesse montar o disco físico como ro no sistema operacional host e copiar os dados em uma unidade USB externa. O servidor host possui apenas um controlador USB, portanto, a passagem de PCI não é uma opção.

— Zhuoyun Wei 25/11

Respostas:

Não. Não fornecerá resultados consistentes no cliente somente leitura, devido ao cache. Definitivamente não foi projetado para isso. Você pode esperar ver erros de E / S retornados aos aplicativos. Provavelmente ainda há algumas omissões no código, que podem causar uma falha no kernel ou memória corrompida usada por qualquer processo.

Mas o mais importante é que o ext4 repete o diário mesmo em montagens somente leitura. Portanto, uma montagem somente leitura ainda gravará no dispositivo de bloco subjacente. Seria inseguro, mesmo que as duas montagens fossem apenas de leitura :).

— sourcejedi
fonte

Como você diz, montar somente leitura não garante que o sistema de arquivos seja intocado. Se você ainda quer tentar para fins "educacional" sem correr riscos, você deve definir o seu dispositivo de somente leitura: blockdev --setro /dev/sda1.

— Totor 22/03

Essa é uma informação interessante sobre a montagem ext4. Suponho que se possa evitar esse problema forçando a montagem somente leitura ext2?

— Bananguin 22/03

Eu encontrei esse trecho de código que deixe-me montar um dispositivo de bloco só de leitura em uma VM: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/...

— isaaclw

Isso evitará a corrupção de dados, mas provavelmente não será o que você deseja fazer. Nunca notei problemas ao montar o volume somente leitura em outro nó. Mesmo que algo não corresponda no nó ro normalmente que apenas lança um "inode livre inesperado, execute o e2fsck" ou algo semelhante em / var / log / messages. Se algo for terrivelmente inesperado em um sistema de arquivos não crítico ("/ opt / mySpecialmount"), normalmente o Linux montará o volume somente leitura (ei, já estamos lá). Se você estiver super preocupado com o efeito do cache, tente algum tipo de regime drop_caches / vfs_cache_pressure.

Para evitar a reprodução do diário, adicione "noload" aos argumentos de montagem, faça isso junto com errors = remount-ro (apenas para errar por precaução).

Dito isso, as chances são de que, se você não tiver problemas em montá-lo somente leitura, provavelmente será apenas uma referência para o outro nó. Nesse caso, o NFS ou o smbfs resolveria o problema e foi projetado para um pouco mais de simultaneidade do que o ext3 / 4 seria. Se você precisar de desempenho, poderá procurar em um sistema de arquivos em cluster (um pouco mais de sobrecarga administrativa, mas existe se o desempenho realmente for algo que você precisa).

— Bratchley
fonte

" Isso evitará corrupção de dados ": talvez não, veja a resposta do sourcejedi e meu comentário .

— 22413 Totor

"pular a repetição do diário levará ao sistema de arquivos que contém inconsistências que podem levar a vários problemas" - man mount. Eu posso imaginar que existem aplicativos que detectariam e / ou tolerariam dados inconsistentes em seus arquivos, mas você não mencionou nenhuma ressalva até agora :).

— sourcejedi

@sourcejedi Eles dizem isso porque estão tentando dizer às pessoas os riscos de deixar de lado o diário. Tudo bem, porque a suposição é de que o outro nó fará o trabalho de diário para o outro nó, estamos apenas tentando evitar o trabalho duplo. Fazemos isso em um de nossos servidores de desenvolvimento (não minha escolha, eu teria feito o NFS) e montamos essa coisa sem sequer um drop_caches por quase um ano, sem nenhum problema. Nós dois mencionamos que entradas de cache do FS não antigas podem render dados antigos, mas cabe ao administrador decidir se isso é viável.

— Bratchley

Não vou tentar enumerar todas as irregularidades no comentário acima. Mas, como um ponto de dados, não se trata apenas de dados de arquivo obsoletos no cache do VFS. O ext4 também terá caches das estruturas de dados internas do sistema de arquivos ("metadados"). Você pode acabar lendo os dados de um arquivo excluído, que foi posteriormente substituído por um novo arquivo. Esse é o tipo de advertência que você realmente deseja conhecer antecipadamente, mesmo que isso ocorra com pouca frequência.

— sourcejedi

Analisando seu comentário, acho que você pode estar tentando se referir ao cache no nível de bloco, que é o cache da E / S do dispositivo de bloco na memória. Nesse caso, não é cache que ocorre no próprio, é o cache de metadados DE próprio metadados. Ele também existe fora de qualquer driver do sistema de arquivos, portanto o ext4 / btrfs / etc não tem nenhum gerenciamento dele.

— Bratchley