Formateé EXT4 un disco duro con e2fsprogs 1.45.6-2 en un ArchLinux de 64 bits (Kernel 5.4.50) y lo llené con datos. Luego lo instalé en una computadora diferente con Debian Jessie de 32 bits (Kernel 3.16.84-1) con e2fsprogs 1.42.12-2+deb8u2 y le copié un solo archivo.
¿Es problemática esta diferencia de versión y podría haber causado daños al sistema de archivos?
Durante el apagado del sistema Jessie de 32 bits, noté un mensaje de error e2fsck, que básicamente decía que no se puede ejecutar debido a metadata_csum.
Entonces busqué en Google y descubrí que las sumas de verificación de metadatos se introdujeron en 1.43: https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
Lo que me hace sentir realmente incómodo es la siguiente cita... NO debería ser posible que el código fs antiguo escriba en un sistema de archivos con sumas de verificación de metadatos habilitadas. El indicador metadata_csum se implementa como un indicador ROCOMPAT, lo que debería evitar que los programas antiguos (no maliciosos) estropeen las cosas.
Esperaba no poder montar el sistema de archivos en absoluto si hay algún problema de incompatibilidad, pero realmente temo haber estropeado el FS.
Cualquier ayuda en esto sería muy apreciada.
Editar: utilicé GParted para crear el FS y, mientras tanto, aprendí que, a diferencia de mke2fs, crea sistemas de archivos en modo de 32 bits de forma predeterminada para unidades <16 TiB, que es el caso de mi unidad de 8 TB. Verifiqué esto verificando las características de los sistemas de archivos proporcionadas por tune2fs -l /dev/sda | grep features, que de otro modo incluirían el término '64 bits'.
Respuesta1
Hay dos comprobaciones de compatibilidad independientes; uno es por el kernel y el otro por las utilidades e2fsprogs. El kernel 3.16 admite sumas de comprobación de metadatos, por lo que no hubo problemas para montarlo. Sin embargo, la versión de e2fsprogs en Debian Jessie no lo hizo. Entonces, los intentos de verificar el sistema de archivos usando e2fsck fallaron porque la versión de e2fsprogs era demasiado antigua. No estoy seguro de qué programa estaba intentando ejecutar e2fsck, pero aparentemente ignoró el estado de salida de e2fsck y/o tal vez lo montó manualmente.
Eso explica por qué pudo montar el sistema de archivos a pesar de que e2fsck dijo que no podía verificar el sistema de archivos.
Sin embargo, la otra advertencia es que 3.16 es unmuykernel antiguo, y si bien algunas correcciones de errores están respaldadas, no todas lo son, y 3.16 dejó de recibir respaldos hace mucho, mucho, MUCHO tiempo. Y la versión 3.16 fue bastante poco después de que se implementaran las sumas de verificación de metadatos, y no puedo al menostodogarantice que no haya errores relacionados con las sumas de verificación de metadatos en 3.16.84. Pero si solo copió un único archivo a ese sistema de archivos, el contenido del archivo se verifica y una versión moderna de e2fsck no detecta ningún problema, probablemente esté bien.