Se trata de un sistema de archivos ext4 en un volumen lógico administrado con LVM en un cifrado LUKS en un RAID de hardware. El sistema operativo es un Ubuntu 22.04 LTS genérico.
Desafortunadamente, el RAID falló recientemente y el sistema de archivos se reasignó como de solo lectura en ese momento. Después de detener todas las aplicaciones que escriben en ese sistema de archivos, el RAID podría restaurarse por completo con un poco de suerte. Y, con aún más suerte, ¡el sistema de archivos aún es completamente legible con los datos restaurados! Y e2fsckni siquiera encontré errores.
Entonces ¿está todo bien? Lamentablemente no. Desafortunadamente, todavía hay una gran cantidad (cientos de megabytes) de datos no escritos en la memoria y no sé cómo sacarlos al disco. Es por eso que no he reiniciado todavía, y es también por eso que no quiero reiniciar, porque reparar todos los archivos de la base de datos con esos datos faltantes será un trabajo importante. La presencia de datos no escritos se puede verificar fácilmente mediante:
sync ; grep Dirty /proc/meminfo
que normalmente produce sólo unos pocos kilobytes, pero en mi caso da cientos de megabytes. Desafortunadamente, no sé en qué nivel de los diversos controladores del kernel se encuentran los datos: caché del disco físico, uno de los grupos de volúmenes o el sistema de archivos real.
Reparaciones intentadas hasta ahora
Mi primer intento ha sido volver a montar el sistema de archivos que aún es de solo lectura como lectura y escritura mediante:
mount -o remount /dev/mapper/vg1-data
Desafortunadamente, esto genera el mensaje de error:
mount: /data: cannot remount /dev/mapper/vg1-data read-write, is write-protected.
Sin embargo, el volumen real es de lectura y escritura, como se puede verificar mediante:
cat /sys/block/dm-*/ro
lo que da el resultado 0de todo lo que está bajo el control del asignador de dispositivos, incluidos los volúmenes encima del RAID. Lo mismo ocurre con el sdpropio dispositivo. Además:
dmsetup info vg1-data
informa el estado del volumen como ACTIVE. En cambio, informaría el estado como ACTIVE (READ-ONLY), si fuera de solo lectura. De manera similar, lvsmuestra atributos normales de -wi-ao----.
una gran pista, que la capacidad de lectura y escritura del sistema de archivos NO es en realidad la fuente del problema, está disponible a través de tune2fs -l. Esto imprime, entre muchas otras estadísticas, esta información sobre el último error en el sistema de archivos montado:
Last error time: Wed Jan 17 18:47:43 2024
Last error function: ext4_remount
Last error line #: 5822
Last error err: EBUSY
En el momento de ese error, hay esta línea críptica escrita en el syslog:
EXT4-fs error (device dm-N): ext4_remount:5822: comm mount: Abort forced by user
Cuando fuerzo explícitamente el volumen al modo de solo lectura a través de:
dmsetup table vg1-data | dmsetup reload -r vg1-data
dmsetup resume vg1-data
dmsetup info vg1-data
luego, nuevos mountintentos NO actualizan más la marca de tiempo de "Última hora del error", pero arrojan el mismo mensaje de error (y ahora obviamente correcto). Después de volver a utilizar dmsetuppara hacer que el volumen sea de lectura y escritura, nuevos mountintentos actualizarán la marca de tiempo del último error nuevamente y también escribirán en syslog nuevamente.
En otra publicación de serverfault, encontré la sugerencia de configurar los volúmenes del mapeador de disco en solo lectura y luego volver a lectura-escritura, pero eso tampoco funcionó:Software de Linux RAID 1: el sistema de archivos raíz se vuelve de solo lectura después de una falla en un disco
cryptsetup reloadTampoco logró nada.