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

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.

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.

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