Dopo aver eliminato molti file di grandi dimensioni, lo spazio libero aumenta con un grande ritardo

Ieri ho eliminato 71 GB di file sul mio server di casa / media.
Spazio libero prima: 117 GB
Spazio libero dopo: 126 GB

Quindi, invece di avere 71 GB di spazio libero aggiuntivo, avevo solo 9 GB. Ho ricontrollato che nessun file era aperto e ho eliminato 71 GB e lo spazio libero è aumentato solo di 9 GB.

Ho anche provato a sincronizzare, ma nessun effetto.

Questa non è la prima volta che succede. In effetti, ho visto questo comportamento da anni ogni tanto. Prima su ext3, ora su ext4.
Quando ciò accade, posso recuperare lo spazio libero smontando e quindi rimontando il filesystem. In questi casi, lo smontaggio richiede fino a 2 minuti anziché quasi nessun tempo.

Al giorno d'oggi, non riesco facilmente a smontare e rimontare il filesystem, perché è permanentemente occupato dal mio software di videoregistratore, dal server owncloud per la mia famiglia e da alcuni altri servizi che finora non avevo. E non voglio alzarmi alle 3 di notte solo per smontare e rimontare.

No, l'utilità 'at' non funzionerà perché uno dei servizi esegue attività a lungo termine non ripristinabili e quindi ha bisogno di un controllo manuale dello stato per trovare un buon momento in cui può essere chiuso, ovvero un'attività è appena terminata.

Ma questa mattina, ho notato che lo spazio è stato liberato durante la notte. Mi sembra che ci sia stata una sorta di pulizia, e questa potrebbe essere la stessa cosa che richiede più tempo durante lo smontaggio.

Finora ho notato questo comportamento solo durante l'eliminazione di una grande quantità di dati. D'altra parte, non sono sicuro che accada regolarmente e la differenza è troppo piccola per essere notata.

Il filesystem è stato creato con lo 0% riservato a root ( mkfs -m 0). Secondo fsck -f(lo faccio sempre tra smontaggio e rimontaggio), il file system non è danneggiato e, secondo il test esteso di diagnostica SMART, anche l'hardware è OK.

[MODIFICARE]

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

[/MODIFICARE]

Quindi, ecco le mie 2 domande:

Cosa sta succedendo qui? Perché lo spazio viene liberato su umount o con un ritardo anziché immediatamente all'eliminazione?
C'è qualcosa che posso fare per innescare liberare lo spazio in questo momento senza smontare e rimontare?

ext4 ext3

— Markus N.
fonte

Questo mi profuma molto come se i file fossero ancora aperti da qualcosa. Come stai confermando che nessuno dei file è aperto dopo l'eliminazione? lsof | grep -i deleteddi solito è il modo migliore per verificarlo.

— Garrett,

Normalmente non è possibile smontare un filesystem quando i file sono aperti. Quindi, se umount ha esito positivo, non ci sono file aperti. Tranne ieri, ho sempre fatto il ciclo umount, re-mount quando l'ho notato.

— Markus N.

Questo è davvero il caso. Quali sono le opzioni di montaggio ext4?

— Garrett,

noatime, default

— Markus N.

Hai una sorta di sistema di backup in esecuzione che potrebbe conservare copie dei file o, in alternativa, collegamenti ad essi?

— derobert,

Esistono due fattori che potrebbero interagire.

A differenza di Windows, puoi eliminare i file aperti. Se si elimina un filmato in streaming, questo verrà rimosso dalla directory, ma rimarrà comunque come file fino a quando il programma di streaming non lo chiude. Una volta che il software di streaming lo chiude, lo spazio verrà rilasciato. Il fuser -mcomando può essere utilizzato per trovare l'id di processo di tutti i processi con file aperti. Alcuni programmi potrebbero non chiudere immediatamente i file una volta terminati.
Questi sono entrambi file system con journal. Le modifiche vengono scritte su un giornale e quindi impegnate. Il commit delle modifiche può richiedere del tempo. Il sistema operativo spesso memorizza nella cache le modifiche al disco e commette periodicamente modifiche al disco. L'esecuzione del synccomando dovrebbe scaricare tutte le modifiche in sospeso sul disco. Montare il disco con l' syncopzione migliora la velocità su disco, ma lavora il disco più duramente.

— BillThor
fonte

Sì, so di poter eliminare i file aperti. Conosco le relazioni tra voci di directory e inode. Ma sono sicuro che i file non fossero aperti, altrimenti non sarei in grado di smontare il filesystem ... Ma il tuo secondo oggetto sembra interessante. Possono davvero essere necessari più di 30 minuti per il commit dei file eliminati? 30 minuti sono il tempo tra l'eliminazione dei file e andare a letto l'altro ieri, quindi non posso dire quanto tempo ci sia voluto davvero.

— Markus N.

@MarkusN. Alcuni sistemi operativi memorizzano nella cache molti dati del file system. Se lo spazio non è necessario, è possibile che scrivano sufficienti dati del registro delle transazioni per garantire che lo spazio venga liberato, ma impiegano del tempo a liberare spazio. Se si smonta una chiave USB dopo aver scritto molti dati, può richiedere molto tempo per scaricare i dati prima di poterlo rimuovere. È un compromesso tra la scrittura sicura su disco e il non ritardo di altre azioni.

— BillThor,

Grazie per la modifica. Ma come vedi nella mia domanda originale, ho già provato la sincronizzazione senza alcun effetto.

— Markus N.

@MarkusN. Non credo che la sincronizzazione sia efficace come una volta. Probabilmente garantisce solo che i dati del diario siano scritti, non necessariamente che tutte le modifiche siano impegnate. Smonta / monta forzerà l'applicazione del journal. Non conosco la priorità di pianificazione per le eliminazioni, ma mi aspetto che sia relativamente basso. L'esplorazione del codice potrebbe rispondere a più domande.

— BillThor,

Mi sembra ragionevole.

— Markus N.