Hoy eliminé un archivo de 50 GB almacenado en un sistema de archivos ext3 usando el rmcomando. Fueron necesarios rmcasi 40 minutos de intensas operaciones de E/S para liberar todos los bloques. Por lo que veo en otras fuentes, ese es el tiempo que lleva liberar todos los bloques utilizados por el archivo. ¿Qué hubiera pasado si alguien hubiera matado el rmproceso a la mitad? ¿Podría esto haber causado una corrupción del sistema de archivos, con algunos bloques que ya no se pudieron recuperar como espacio libre?
Respuesta1
(es decir, exigir fsck). No es necesaria ninguna inconsistencia del sistema de archivos.
Sí, la liberación del bloque se producirá después de la desvinculación. Pero este proceso no será interrumpible.
__ext2_truncate_blocks ->
ext2_free_branches -> (for loop)
sb_bread ->
wait_on_buffer ->
wait_on_bit_io(&bh->b_state, BH_Lock, TASK_UNINTERRUPTIBLE);
El ejemplo anterior es para ext2, pensé que sería más sencillo de ver. ext3no va a ser diferente...
ext4Aunque debería ser más rápido. El uso de extensiones debería evitar la necesidad debloques triple-indirectos. (El artículo describe cómo agregar extensiones a ext3, pero Linus se resistió y dijo que primero se aumentara el número de versión a ext4). Espero que el tiempo para actualizar los mapas de bits sea el mismo, pero son mucho más compactos que los punteros de bloque.