Après avoir supprimé de nombreux fichiers volumineux, l'espace libre augmente avec un retard important

Hier, j'ai supprimé 71 Go de fichiers sur mon serveur domestique / multimédia.
Espace libre avant: 117 Go
Espace libre après: 126 Go

Donc, au lieu d'avoir 71 Go d'espace libre supplémentaire, je n'avais que 9 Go. J'ai revérifié qu'aucun fichier n'était ouvert et j'ai vraiment supprimé 71 Go et l'espace libre n'a augmenté que de 9 Go.

J'ai aussi essayé de synchroniser, mais sans effet.

Ce n'est pas la première fois que cela se produit. En effet, j'ai vu ce comportement depuis des années de temps en temps. D'abord sur ext3, maintenant sur ext4.
Lorsque cela se produit, je peux récupérer l'espace libre en démontant puis en remontant le système de fichiers. Dans ces cas, le démontage prend jusqu'à 2 minutes au lieu de presque pas de temps.

De nos jours, je ne peux pas facilement démonter et remonter le système de fichiers, car il est occupé en permanence par mon logiciel d'enregistrement vidéo, le serveur owncloud pour ma famille et quelques autres services que je n'avais pas jusqu'à présent. Et je ne veux pas me lever à 3 heures du soir juste pour démonter et remonter.

Non, l'utilitaire 'at' ne fonctionnera pas car l'un des services effectue des tâches de longue durée non résumables et a donc besoin d'une vérification d'état manuelle pour trouver un bon moment où il peut être arrêté, c'est-à-dire qu'une tâche vient de se terminer.

Mais ce matin, j'ai remarqué que l'espace avait été libéré du jour au lendemain. Il me semble qu'il y a eu une sorte de nettoyage, et cela peut être la même chose qui prend du temps supplémentaire lors du démontage.

Jusqu'à présent, je n'ai remarqué ce comportement que lors de la suppression d'une grande quantité de données. En revanche, je ne sais pas si cela se produit régulièrement et la différence est tout simplement trop petite pour être remarquée.

Le système de fichiers a été créé avec 0% réservé à root ( mkfs -m 0). Selon fsck -f(je fais toujours cela entre démonter et remonter), le système de fichiers n'est pas corrompu, et selon le test étendu des diagnostics SMART, le matériel est également OK.

[ÉDITER]

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  

[/ÉDITER]

Voici donc mes 2 questions:

1. Que se passe-t-il ici? Pourquoi l'espace est-il libéré à umount ou avec un retard au lieu d'être immédiatement supprimé?
2. Puis-je faire quelque chose pour déclencher la libération de l'espace dès maintenant sans démonter ni remonter?

Il y a deux facteurs qui peuvent interagir.

• Contrairement à Windows, vous pouvez supprimer les fichiers ouverts. Si vous supprimez un film en cours de diffusion, il sera supprimé du répertoire, mais existera toujours sous forme de fichier jusqu'à ce que le programme de diffusion en continu le ferme. Une fois le logiciel de streaming fermé, l'espace sera libéré. La fuser -mcommande peut être utilisée pour trouver l'ID de processus de tout processus avec des fichiers ouverts. Certains programmes peuvent ne pas fermer immédiatement les fichiers lorsqu'ils en ont fini avec eux.

• Il s'agit de deux systèmes de fichiers journalisés. Les modifications sont écrites dans un journal puis validées. Cela peut prendre un certain temps avant que les modifications ne soient validées. Le système d'exploitation met souvent en cache les modifications du disque et ne valide les modifications sur le disque que périodiquement. L'exécution de la synccommande doit vider toutes les modifications en attente sur le disque. Le montage du disque avec l' syncoption améliorera la vitesse sur le disque, mais le travail sera plus difficile.