¿Se puede montar el mismo disco ext4 desde dos hosts, uno de solo lectura?

Sé que montar el mismo disco con un sistema de archivos ext4 desde dos servidores diferentes (es un iSCSI vloume) probablemente dañará los datos en el disco. Mi pregunta es ¿hará alguna diferencia si uno de los servidores monta el disco de solo lectura mientras que el otro lo monta de lectura-escritura?

Sé que OCFS2 o similares podrían usarse para esto y que podría exportar el disco con NFS para que sea accesible al otro servidor, pero me gustaría saber si la configuración que propongo funcionará.

linux mount ext4

— Fernando
fuente

Podría funcionar solo si ambos montan solo lectura (y con eso quiero decir verdadero solo lectura que no escribe). Tan pronto como un lado monta lectura-escritura, el otro lado (solo lectura montado) no espera cambios por el otro lado (lectura-escritura montada) y, por lo tanto, lee datos corruptos. Lo que necesita es un sistema de archivos compatible con clústeres o un único servidor que exponga un sistema de archivos de red al otro.

— frostschutz

@frostschutz Sí, ambos ro funcionarán pero no sin trucos, ya que el montaje en ro de ext4 sí escribe en el disco real (necesita un bucle ro y una superposición cada uno).

— Ned64

Compartiré un caso de uso aquí: un servidor físico y un servidor virtual están compartiendo un disco físico con transferencia de disco. El servidor virtual está montando el disco como rw. Me gustaría copiar una gran cantidad de datos del disco, pero la red es demasiado lenta. Sería genial si pudiera montar el disco físico como ro en el sistema operativo host y copiar los datos en una unidad USB externa. El servidor host solo tiene un controlador USB, por lo que el paso PCI no es una opción.

— Zhuoyun Wei

Respuestas:

No. No dará resultados consistentes en el cliente de solo lectura, debido al almacenamiento en caché. Definitivamente no está diseñado para eso. Podría esperar ver errores de E / S devueltos a las aplicaciones. Probablemente todavía exista un cierto número de descuidos en el código, que podrían causar un bloqueo del núcleo o dañar la memoria utilizada por cualquier proceso.

Pero lo más importante, ext4 reproduce el diario incluso en montajes de solo lectura. Por lo tanto, una montura de solo lectura seguirá escribiendo en el dispositivo de bloque subyacente. Sería inseguro incluso si ambas monturas fueran de solo lectura :).

— sourcejedi
fuente

Como usted dice, el montaje de solo lectura no garantiza que el sistema de archivos quede intacto. Si todavía quiere probar con fines "educativos" sin tomar riesgos, usted debe configurar su dispositivo de sólo lectura: blockdev --setro /dev/sda1.

— Totor

Esa es una información interesante sobre el montaje ext4. ¿Supongo que uno podría evitar este problema forzando el montaje de solo lectura ext2?

— Bananguin

Encontré este fragmento de código que me permitió montar un dispositivo de bloque de solo lectura en una VM: sudo mount -t ext4 -o ro,loop,noload /dev/vda /mnt/ digital-forensics.sans.org/blog/2011/06/14/…

— isaaclw

Esto evitará la corrupción de datos, pero probablemente no sea lo que desea hacer. Nunca he notado ningún problema al montar el volumen de solo lectura en otro nodo. Incluso si algo no coincide en el nodo ro que generalmente arroja un "inodo libre inesperado, ejecute e2fsck" o similar en / var / log / messages. Si algo es terriblemente inesperado acerca de un sistema de archivos no crítico ("/ opt / mySpecialmount"), por lo general, Linux solo montará el volumen de solo lectura (oye, ya estamos allí). Si está súper preocupado por el efecto que tiene el almacenamiento en caché, puede intentar obtener algún tipo de régimen drop_caches / vfs_cache_pressure.

Para evitar reproducir el diario, agregue "noload" a los argumentos de montaje, hágalo junto con errors = remount-ro (solo para errar por precaución).

Dicho esto, lo más probable es que si está de acuerdo con montarlo de solo lectura, probablemente sea solo como una referencia para el otro nodo, en cuyo caso NFS o smbfs resolverían el problema y está diseñado para un poco más de concurrencia que ext3 / 4 serían. Si necesita rendimiento, puede buscar en un sistema de archivos en clúster (un poco más de gastos administrativos, pero está ahí si el rendimiento es realmente algo que necesita).

— Bratchley
fuente

" Esto evitará la corrupción de datos ": puede que no, vea la respuesta de sourcejedi y mi comentario .

— Totor

"omitir la reproducción del diario conducirá a que el sistema de archivos contenga inconsistencias que pueden ocasionar cualquier número de problemas" - man mount. Me imagino que hay aplicaciones que detectarían y / o tolerarían datos inconsistentes en sus archivos, pero hasta ahora no ha mencionado ninguna advertencia de este tipo :).

— sourcejedi

@sourcejedi Dicen eso porque están tratando de decirle a la gente los riesgos de dejar de lado efectivamente el diario. Esto está bien, porque se supone que el otro nodo realizará el trabajo de diario para el otro nodo, solo estamos tratando de evitar el doble trabajo. Hacemos esto en uno de nuestros servidores de desarrollo (no es mi elección, hubiera hecho NFS) y he tenido esa cosa montada sin siquiera drop_caches durante casi un año sin ningún problema. Ambos hemos mencionado que las entradas de caché FS no obsoletas pueden generar datos antiguos, pero en última instancia, depende del administrador decidir si esto es viable.

— Bratchley

No voy a intentar enumerar todo lo incorrecto en el comentario anterior. Pero como un punto de datos, no se trata solo de datos de archivos obsoletos en el caché VFS. ext4 también tendrá cachés de las estructuras de datos internos del sistema de archivos ("metadatos"). Podría terminar leyendo datos de un archivo eliminado, que posteriormente fue sobrescrito por un nuevo archivo. Ese es el tipo de advertencia que realmente desea conocer de antemano, incluso si solo va a suceder con poca frecuencia.

— sourcejedi

Mirando hacia atrás a su comentario, creo que puede estar tratando de referirse al almacenamiento en caché a nivel de bloque, que es el almacenamiento en caché de la E / S del dispositivo de bloque en la memoria. En cuyo caso, no es el almacenamiento en caché lo que ocurre en los metadatos en sí, es el almacenamiento en caché de los metadatos en sí. También existe fuera de los controladores del sistema de archivos, por lo que ext4 / btrfs / etc no tiene ninguna administración.

— Bratchley