¿Por qué apagar mi máquina después de un mal `rm` salvó mis archivos?

31

Situación clásica: corrí un rmerror y me di cuenta inmediatamente después de que había eliminado los archivos incorrectos. (Nada crítico y tenía copias de seguridad tolerablemente recientes, pero aún molesto).

Sabiendo que una mayor actividad del disco era mi enemigo si quería recuperar los archivos con extundeleteo tales herramientas, inmediatamente apagué la máquina físicamente (es decir, con el botón de encendido, no con haltninguno de estos comandos). Esta era una computadora portátil sin tareas importantes en ejecución ni nada abierto, por lo que era una operación aceptable. (Por cierto, aprendí desde entonces que lo primero que debería hacer en tal situación sería estimar primero si los archivos faltantes aún pueden abrirse mediante un proceso https://unix.stackexchange.com/a/101247 - si es así, debe recuperarlos de esta manera en lugar de apagar la máquina).

Aún así, una vez que la máquina se apagó, pensé por un momento y decidí que los archivos no valían la inversión de tiempo para arrancar un sistema en vivo para un análisis forense adecuado. Entonces volví a encender la máquina. Y luego descubrí que mis archivos todavía estaban en el disco: rmno se habían propagado al disco antes de que me apagara. Bailé un poco y agradecí al dios de los administradores de sistemas por su inesperado perdón.

Mi pregunta ahora es entender cómo esto fue posible y cuál es la demora típica antes de que una rmse propague realmente al disco. Sé que el disco IO no se enjuaga de inmediato, pero que se queda en la memoria durante algún tiempo, pero pensé que el diario del disco se aseguraría rápidamente de que las operaciones pendientes no se pierdan por completo. https://unix.stackexchange.com/a/78766 parece insinuar un mecanismo separado para enjuagar páginas sucias y enjuagar las operaciones del diario, pero no proporciona detalles suficientes sobre cómo estaría involucrado el diario durante un rm, y el retraso esperado antes las operaciones se sonrojan.

Algunos detalles más: los datos estaban en una partición ext4 dentro de un volumen LUKS, y al reiniciar la máquina vi lo siguiente en syslog:

Sep 24 10:24:58 gamma kernel: [   11.457007] EXT4-fs (dm-0): 1 orphan inode deleted
Sep 24 10:24:58 gamma kernel: [   11.458393] EXT4-fs (dm-0): recovery complete
Sep 24 10:24:58 gamma kernel: [   11.482475] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

pero no estoy seguro de que esté relacionado con el rm.

Otra pregunta sería si hay una manera de decirle al núcleo que no realice ninguna de las operaciones de disco pendientes (sino, digamos, volcarlas en algún lugar), en lugar de apagar la máquina. (Por supuesto, parece peligroso no realizar las operaciones pendientes, pero esto es lo que sucedería al apagar la máquina de todos modos, y en algunos casos podría salvarlo). Esto sería "más limpio", por supuesto, y también interesante por ejemplo, servidores remotos donde el apagado físico no es una opción fácil.

a3nm
fuente

Respuestas:

22

Parece que tienes una comprensión decente de lo que sucedió.

Sí, debido a que apagó el sistema antes de que sus cambios se confirmaran en el disco, estaban allí cuando reinició.

El sistema almacena en caché todas las escrituras antes de vaciarlas al disco. Hay varias opciones que controlan este comportamiento, todas ubicadas en /proc/sys/vm/dirty_* [ kernel doc ] . A menos que una aplicación realice explícitamente un vaciado a través de fsync() [ man 2 fsync ] , los datos se confirman cuando tienen la edad suficiente o se llena la memoria caché de escritura.
La definición de "datos" como se usa anteriormente incluye la modificación de la entrada del directorio para eliminar el archivo.

Ahora, en cuanto a la revista, esa es una de las ideas erróneas comunes de para qué sirve la revista. El propósito de un diario no es garantizar que los cambios se reproduzcan o que no se pierdan datos. El propósito de una revista es evitar la corrupción del sistema de archivos en sí, no los archivos que contiene. El diario simplemente contiene información sobre los cambios que se están realizando y no (típicamente) los datos completos del cambio en sí. Los detalles exactos dependen del sistema de archivos y del modo de diario. Para ext3 / 4, vea la dataopción de montaje en man 8 mount.


Para responder a su pregunta complementaria sobre si hay una manera de evitar las escrituras pendientes sin reiniciar:

Al hacer una lectura rápida del código fuente del kernel, parece que puede usar el ucomando magic sysrq ([ wikipedia ], [ kernel doc ]) para realizar una operación de emergencia de remontaje de solo lectura. Parece que esto remontará inmediatamente todos los volúmenes de solo lectura sin una operación de sincronización.

Para usar esto, simplemente presione Alt+ SysRq+ u.

Patricio
fuente
1
Gracias por esta respuesta! Todavía estoy un poco confundido sobre el diario: ¿debería pensarlo como algo que solo se involucra cuando los cambios se vuelven al disco, de modo que el almacenamiento en caché de escritura es el único mecanismo relevante para estimar el tiempo de gracia antes de que rmse escriba? En otras palabras, ¿las cosas se comprometen con el diario solo cuando una escritura está a punto de realizarse? ¿O es la imagen más compleja que eso? En cuanto a alt-sysrq-u, esta es una idea bastante clara. ¿Tiene una referencia que dar para el reclamo "Parece"? (Parece que no se sigue de los enlaces que usted dio). ¡Gracias! :)
a3nm
Además, magic sysrq también tiene la limitación de que aún no puede hacerlo en una máquina remota.
a3nm
3
@ a3nm Puede usar sysrq en una máquina remota. echo u > /proc/sysrq-trigger(es posible que deba activarlo primero).
Paulo Almeida
El diario no trata con el contenido del archivo (de forma predeterminada, se puede cambiar por completo), solo con los metadatos del sistema de archivos, pero en este caso podría haber eliminado el archivo , ya que estamos tratando de eliminar la entrada del directorio. Por lo tanto, el diario debe asegurarse de que el archivo existe (con sus contenidos anteriores, suponiendo que no hayan tenido otros cambios) o no.
Ángel
@ a3nm Respecto a tu comentario en el diario. La caché de escritura se encuentra entre el diario y el disco. Cuando escribe en el sistema de archivos, el diario se actualiza, luego el sistema de archivos, pero ninguno de los dos está confirmado en el disco todavía.
Patrick
2

De: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

commit = nrsec (*) Se le puede decir a Ext4 que sincronice todos sus datos y metadatos cada 'nrsec' segundos. El valor predeterminado es 5 segundos. Esto significa que si pierde su poder, perderá tanto como los últimos 5 segundos de trabajo (sin embargo, su sistema de archivos no se dañará, gracias al registro en diario). Este valor predeterminado (o cualquier valor bajo) afectará el rendimiento, pero es bueno para la seguridad de los datos. Establecerlo en 0 tendrá el mismo efecto que dejarlo en el valor predeterminado (5 segundos). Establecerlo en valores muy grandes mejorará el rendimiento.

Vea también aquí cómo vaciarlos : ¿Cómo vaciar las memorias intermedias y la memoria caché en un sistema Linux?

Citado del enlace de arriba:

NOTA: limpie la memoria de cosas innecesarias (Kernerl 2.6.16 o más reciente). ¡Siempre asegúrese de ejecutar la sincronización primero para eliminar cosas útiles en el disco!

To free pagecache:

$ echo 1 > /proc/sys/vm/drop_caches

To free dentries and inodes:

$ echo 2 > /proc/sys/vm/drop_caches

To free pagecache, dentries and inodes:

$ echo 3 > /proc/sys/vm/drop_caches
David
fuente
Gracias por esta respuesta! Sin embargo, no entiendo esto: en cuanto a esta "sincronización" que se menciona commit=nrsec, ¿es algo que ocurriría después de que el núcleo haya decidido eliminar los cambios de la memoria al disco? ¿O la configuración commit=1garantiza que todos los cambios se eliminarán después de 1 segundo, independientemente de la configuración dirty_expire_centisecsy dirty_writeback_centisecs?
a3nm
El núcleo vaciará (sincronizará) cualquier caché / búfer en el disco cada 1 segundo commit=1. Según tengo entendido, syncobliga a que todo suceda independientemente de la configuración de la memoria virtual, aunque puede suceder antes.
David
Además, por razones de rendimiento, (y la longevidad del almacenamiento) no se recomienda una configuración inferior a la predeterminada.
David