Después de eliminar muchos archivos grandes, el espacio libre aumenta con un gran retraso

Ayer, eliminé 71 GB de archivos en mi servidor doméstico / multimedia.
Espacio libre antes: 117 GB
Espacio libre después: 126 GB

Entonces, en lugar de tener 71 GB de espacio libre adicional, solo tenía 9 GB. He verificado dos veces que no hay archivos abiertos y realmente he eliminado 71 GB y el espacio libre realmente aumentó solo 9 GB.

También intenté sincronizar, pero sin efecto.

Esta no es la primera vez que sucede. De hecho, he visto este comportamiento desde hace años de vez en cuando. Primero en ext3, ahora en ext4.
Cuando esto sucede, puedo reclamar el espacio libre desmontando y luego volviendo a montar el sistema de archivos. En estos casos, desmontar toma hasta 2 minutos en lugar de casi ningún tiempo.

Hoy en día, no puedo desmontar y volver a montar fácilmente el sistema de archivos, ya que está permanentemente ocupado desde mi software de grabación de video, el servidor owncloud para mi familia y algunos servicios más que no tenía hasta ahora. Y no quiero levantarme a las 3 en punto de la noche solo para desmontar y volver a montar.

No, la utilidad 'at' no funcionará porque uno de los servicios realiza tareas de larga duración no reanudables y, por lo tanto, necesita una verificación manual del estado para encontrar un buen momento en el que pueda cerrarse, es decir, una tarea acaba de finalizar.

Pero esta mañana, noté que el espacio había sido liberado de la noche a la mañana. Me parece que hubo algún tipo de limpieza, y esto puede ser lo mismo que toma el tiempo adicional al desmontar.

Hasta ahora, solo noté este comportamiento al eliminar una gran cantidad de datos. Por otro lado, no estoy seguro de si sucede regularmente y la diferencia es demasiado pequeña para notarla.

El sistema de archivos se creó con 0% reservado para root ( mkfs -m 0). De acuerdo con fsck -f(siempre hago esto entre desmontar y volver a montar), el sistema de archivos no está dañado y, de acuerdo con la prueba extendida de diagnóstico SMART, el hardware también está bien.

[EDITAR]

tune2fs 1.42 (29-Nov-2011)  
Filesystem volume name:   bigdata  
Last mounted on:          /bigdata  
Filesystem UUID:          6aebd17a-e064-41dc-9c68-c9a3acbe4f66  
Filesystem magic number:  0xEF53  
Filesystem revision #:    1 (dynamic)  
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize  
Filesystem flags:         signed_directory_hash   
Default mount options:    user_xattr acl  
Filesystem state:         clean  
Errors behavior:          Continue  
Filesystem OS type:       Linux  
Inode count:              121413632  
Block count:              485645568  
Reserved block count:     0  
Free blocks:              29081276  
Free inodes:              121382378  
First block:              0  
Block size:               4096  
Fragment size:            4096  
Reserved GDT blocks:      908  
Blocks per group:         32768  
Fragments per group:      32768  
Inodes per group:         8192  
Inode blocks per group:   512  
Flex block group size:    16  
Filesystem created:       Tue Dec 25 23:42:35 2012  
Last mount time:          Fri Jan  3 17:37:36 2014  
Last write time:          Fri Jan  3 17:37:36 2014  
Mount count:              37  
Maximum mount count:      -1  
Last checked:             Thu Apr 18 17:03:40 2013  
Check interval:           0 (<none>)  
Lifetime writes:          14 TB  
Reserved blocks uid:      0 (user root)  
Reserved blocks gid:      0 (group root)  
First inode:              11  
Inode size:           256  
Required extra isize:     28  
Desired extra isize:      28  
Journal inode:            8  
Default directory hash:   half_md4  
Directory Hash Seed:      be2b977e-5127-4843-9123-fe33b6d7b573  
Journal backup:           inode blocks

[/EDITAR]

Así que aquí están mis 2 preguntas:

¿Que está sucediendo aquí? ¿Por qué se libera espacio en el montaje o con un retraso en lugar de inmediatamente en la eliminación?
¿Hay algo que pueda hacer para activar la liberación del espacio en este momento sin desmontar y volver a montar?

ext4 ext3

— Markus N.
fuente

Esto me huele mucho a que los archivos todavía están abiertos por algo. ¿Cómo confirma que ninguno de los archivos está abierto después de la eliminación? lsof | grep -i deletedsuele ser la mejor manera de verificar esto.

— Garrett

Normalmente no puede desmontar un sistema de archivos cuando los archivos están abiertos. Entonces, si umount tiene éxito, no hay archivos abiertos. Excepto ayer, siempre hice el ciclo de desmontar y volver a montar cuando noté esto.

— Markus N.

Este es de hecho el caso. ¿Cuáles son sus opciones de montaje ext4?

— Garrett

noatime, valores predeterminados

— Markus N.

¿Tiene algún tipo de sistema de copia de seguridad en ejecución que podría mantener copias de los archivos, o alternativamente enlaces duros a ellos?

— derobert

Hay dos factores que pueden estar interactuando.

A diferencia de Windows, puede eliminar archivos que están abiertos. Si elimina una película que se está transmitiendo, se eliminará del directorio, pero seguirá existiendo como un archivo hasta que el programa de transmisión la cierre. Una vez que el software de transmisión lo cierre, se liberará el espacio. El fuser -mcomando se puede usar para encontrar la identificación del proceso de cualquier proceso con archivos abiertos. Es posible que algunos programas no cierren archivos de inmediato cuando terminen con ellos.
Ambos son sistemas de archivos registrados. Los cambios se escriben en un diario y luego se confirman. Los cambios pueden tardar un tiempo en confirmarse. El sistema operativo a menudo guardará en caché los cambios en el disco y solo confirmará cambios en el disco periódicamente. La ejecución del synccomando debería eliminar los cambios pendientes en el disco. Montar el disco con la syncopción mejorará la velocidad al disco, pero trabaja el disco más duro.

— BillThor
fuente

Sí, sé que puedo eliminar archivos que están abiertos. Sé sobre las relaciones entre las entradas de directorio y los inodes. Pero estoy seguro de que los archivos no estaban abiertos, de lo contrario no podría desmontar el sistema de archivos ... Pero su segundo elemento parece interesante. ¿Realmente puede tomar más de 30 minutos para que los archivos eliminados se comprometan? 30 minutos es el tiempo entre eliminar los archivos y acostarse anteayer, así que no puedo decir cuánto tiempo realmente tomó.

— Markus N.

@MarkusN. Algunos sistemas operativos almacenan en caché una gran cantidad de datos del sistema de archivos. Si no se necesita el espacio, pueden escribir suficientes datos de registro de transacciones para garantizar que se libere el espacio, pero tómese su tiempo para liberarlo. Si desmonta una llave USB después de escribir una gran cantidad de datos, los datos pueden demorar mucho tiempo antes de que pueda eliminarlos. Es una compensación entre escribir de forma segura en el disco y no retrasar otras acciones.

— BillThor

Gracias por la edición Pero como puede ver en mi pregunta original, ya intenté sincronizar sin efecto.

— Markus N.

@MarkusN. No creo que la sincronización sea tan efectiva como lo era antes. Es probable que solo garantice que los datos del diario estén escritos, no necesariamente que todos los cambios estén confirmados. Desmontar / montar obligará a aplicar el diario. No sé la prioridad de programación para las eliminaciones, pero esperaría que sea relativamente baja. Explorar el código puede responder más de sus preguntas.

— BillThor

A mí me parece razonable.

— Markus N.