Il modo migliore per liberare spazio su disco dai file eliminati che vengono tenuti aperti


28

Ciao, ho molti file che sono stati eliminati, ma per qualche motivo lo spazio su disco associato ai file eliminati non può essere utilizzato fino a quando non uccido esplicitamente il processo per il file che occupa lo spazio su disco

$ lsof /tmp/
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)

Lo spazio su disco occupato dal file cancellato sopra causa problemi come quando provo ad usare il tasto tab per completare automaticamente un percorso di file ottengo l'errore bash: cannot create temp file for here-document: No space left on device

Ma dopo aver eseguito kill -9 1623lo spazio per quel PID viene liberato e non ricevo più l'errore.

Le mie domande sono:

  • perché questo spazio non viene immediatamente liberato alla prima eliminazione del file?
  • qual è il modo migliore per recuperare lo spazio file associato ai file eliminati?

e per favore fatemi sapere qualsiasi terminologia errata che ho usato o qualsiasi altra informazione pertinente e pertinente riguardo a questa situazione.

Risposte:


26

Sui unice, i nomi dei file sono solo puntatori (inode) che puntano alla memoria in cui risiede il file (che può essere un disco rigido o persino un file system supportato dalla RAM). Ogni file registra il numero di collegamenti ad esso: i collegamenti possono essere sia il nome del file (plurale, se ci sono più collegamenti fissi allo stesso file), sia ogni volta che un file viene aperto, il processo contiene effettivamente il "collegamento" per lo stesso spazio.

Lo spazio viene fisicamente liberato solo se non sono rimasti collegamenti (pertanto, è impossibile raggiungerlo). Questa è l'unica scelta sensata: mentre il file viene utilizzato, non è importante se qualcun altro non può più accedervi: lo stai usando e fino a quando non lo chiudi, hai ancora il controllo su di esso - non noterai nemmeno il nome del file è andato o spostato o altro. Viene anche usato per i tempfile: alcune implementazioni creano un file e lo scollegano immediatamente, quindi non è visibile nel filesystem, ma il processo che lo ha creato lo sta usando normalmente. Il plugin Flash è particolarmente affezionato a questo metodo: tutti i file video scaricati sono tenuti aperti, ma il filesystem non li mostra.

Quindi, la risposta è, mentre i processi hanno ancora i file aperti, non dovresti aspettarti di recuperare lo spazio. Non viene liberato, viene utilizzato attivamente. Questo è anche uno dei motivi per cui le applicazioni dovrebbero davvero chiudere i file quando finiscono di usarli. Nell'uso normale, non dovresti pensare a quello spazio come libero e anche questo non dovrebbe essere molto comune - ad eccezione dei file temporanei che sono scollegati di proposito, non dovrebbero esserci davvero file che considera di essere inutilizzato, ma ancora aperto. Prova a verificare se esiste un processo che lo fa molto e considera come lo usi o trova solo più spazio.


24

I file vengono eliminati dal filesystem dove viene eliminato qualsiasi riferimento a questo inode. Il riferimento può essere su disco (collegamento in qualsiasi directory) e ... da applicazioni aperte. Se rimuovi il file, elimini solo il riferimento dal disco, ma c'è ancora riferimento dall'applicazione.

Puoi "liberare" spazio in due modi:

  1. come accennato in precedenza - puoi uccidere l'applicazione, che apre il file.
  2. puoi ... troncare il file. Anche se viene eliminato:

Se conosci pid - guarda quali file sono aperti da questo pid: ls -l / proc / PID / fd vedi qui link come:

undefine @ uml: ~ $ ls -l / proc / 18596 / fd
razem 0
lrwx ------ 1 undefine undefine 64 lut 1 00:06 0 -> / dev / pts / 30
lrwx ------ 1 undefine undefine 64 lut 1 00:06 1 -> / dev / pts / 30
lrwx ------ 1 undefine undefine 64 lut 1 00:05 2 -> / dev / pts / 30
lr-x ------ 1 undefine undefine 64 lut 1 00:06 3 -> / home / undefine / x (cancellato)
lr-x ------ 1 undefine undefine 64 lut 1 00:06 4 -> anon_inode: inotify

Come vedi - 3 fd è eliminato. puoi troncarlo con il comando (ad esempio):

undefine @ uml: ~ $:> / proc / 18596 / fd / 3
undefine @ UML: ~ $ 

Ricorda che se l'applicazione legge da questo file, può essere pericoloso per loro. Ma - se è solo un file di registro - puoi troncarlo in modo sicuro.


notare che dopo aver troncato il file, il processo originale che lo tiene può ancora aggiungersi alla fine (dove si aspetta la fine). il risultato è apparentemente enorme ma i file sparsi occupano meno spazio sul disco (se il file system supporta i file sparsi) e continuano a crescere!
törzsmókus

sì. Se qualcosa scrive su un file, avverrà sul disco. È difficile evitarlo senza arrestare l'applicazione che scrive su disco;)
undefine

8

Come altri hanno già detto, lsofpossono essere utilizzati per elencare tutti i file eliminati che sono ancora sul disco a causa di descrittori di file aperti. Tuttavia, questa potrebbe essere una lista molto lunga. Ecco un comando che elenca questi file ordinati per dimensione crescente in byte:

sudo lsof -F sn0 | tr -d '\000' | grep deleted | sed 's/^[a-z]*\([0-9]*\)n/\1 /' | sort -n

Potrebbe esserci un modo più conciso di farlo, ma il comando sopra ha funzionato per me.


5

Lo spazio non viene immediatamente liberato perché il processo in esecuzione ha ancora un handle di file aperto sul file appena eliminato. Dopotutto, se un processo sta ancora cercando di usare un file, probabilmente non vuoi davvero che il kernel si sbarazzi di esso (il file). Ciò potrebbe rendere il processo un po 'sconvolto. Il modo migliore (e solo per quanto ne so) di liberare lo spazio è fare esattamente quello che hai fatto: uccidere il processo.


Probabilmente una frase migliore di "proprio come funziona" è "se un processo sta ancora usando un file Unix non dovrebbe cercare di sbarazzarsene."
Bratchley,

Buon punto. L'ho aggiunto alla risposta.
John,

-1

(Menta 17.1)

TL; DR:

  • Ispezionare con sudo baobab(Disk Usage Analyzer).
  • Cancella rootcestino dell'utente.

Contesto

Ero bloccato con uno spazio in costante diminuzione mentre eliminavo costantemente i file. Ho installato il trash-clipacchetto per svuotare il cestino, ma questo non ha aiutato. Alla fine, ho notato che quando ho eseguito baobab(Disk Usage Analyzer nella GUI, almeno su Mint 17.1) per ispezionare la struttura dello spazio su disco, ha dato un avviso che alcune cartelle non erano accessibili. Quindi l'ho eseguito come rootusando sudo baobab. Questo ha rivelato il problema. Molti dei file che erano stati eliminati erano nel cestino rootdell'utente, non nel mio utente. Pertanto, non sono riuscito a liberare lo spazio. Quindi ho semplicemente svuotato il cestino usando come root ( sudo trash-cli) e tutto il mio spazio è tornato.


-1

Prova a usare il comando seguente

lsof | grep deleted

e quindi uccidere il pid del file eliminato.


L'OP è arrivato così lontano; questo non risponde alle loro domande.
Jeff Schaller
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.