L'utilizzo dello spazio su disco non si somma con df & du

Sto cercando di liberare un po 'di spazio su disco: se lo faccio df -h, ho un filesystem chiamato / dev / mapper / vg00-var che dice che sono rimasti 4G, 3.8G, 205M.

Ciò corrisponde alla mia directory / var.

Se scendo in / var e lo faccio du -kscxh *, il totale è 2.1G

2.1G + 200M gratis = 2.3G ... Quindi la mia domanda è: dov'è il restante 1,7G?

linux du df

— Codecraft
fonte

Cosa du -shx /vardice?

— Kyle Smith,

Potresti anche avere file cancellati con handle di file aperti. Il sistema operativo non rilascerà lo spazio fino a quando le maniglie non saranno chiuse, ma non le vedrai con "du". Puoi eseguire "lsof / var | grep delete" (o qualcosa di simile) per vederli. In realtà, questo non sarebbe un risultato sorprendente in, diciamo, / var / log, se i registri vengono ruotati ma il processo di registrazione non è HUP nel modo giusto.

— cjc,

Stavo cancellando alcuni file di registro che erano impazziti, sembrava che non stessero ruotando, ma comunque, avevo ricevuto un'email di una parola da un 'riavvio' di un amico - immaginavo che fosse sarcastico ma apparentemente no :) I ho trovato di nuovo il mio spazio su disco .... disastro evitato (per ora).

— Codecraft

@Codecraft Sì, il riavvio eliminerà sicuramente qualsiasi handle di file aperto, anche se è un po 'come spezzare un uovo con un martello.

— cjc,

@cjc fintanto che avrò la bontà bontà ...! Qualche suggerimento su come potrei cancellare gli handle di file aperti senza martellare il mio uovo?

— Codecraft

Probabilmente hai qualche file di registro, file di database o qualcosa di simile cancellato in giro, in attesa che il processo contenga il rilascio del file.

In Linux, la cancellazione di un file scollega semplicemente il file. Viene effettivamente eliminato quando non ci sono più handle di file collegati a quel file. Pertanto, se si dispone di un file di registro da 2 GB che si elimina manualmente con rm, lo spazio su disco non verrà liberato fino al riavvio del demone syslog (o all'invio del HUPsegnale).

Provare

lsof -n | grep -i deleted

e vedi se hai ancora file zombie cancellati che fluttuano ancora.

— Janne Pikkarainen
fonte

Non sono riuscito a eseguire il tuo comando, ma quello che hai detto sembrava essere scoppiato: avevo ucciso manualmente alcuni log impazziti e, alla fine, un riavvio ha causato il ricalcolo dello spazio su disco e la visualizzazione corretta.

— Codecraft

Ha funzionato per noi con i log di Apache riempiendo la directory / var / log / apache /. Quindi potrebbe non essere necessario riavviare l'intero server, né syslog, solo il servizio che troverai nell'output del comando sopra.

— Yvan,

L'abbiamo appena fatto da soli. Avevamo tomcat6 catalina.out non essere stato catturato da logrotate, l'abbiamo eliminato quando ha raggiunto 4Gb e riparato logrotate. Alcune settimane dopo ci siamo chiesti perché il 4Gb non fosse tornato. Questo lsofcomando ha mostrato che c'erano molti file Tomcat in attesa di eliminazione. Riavvio di Tomcat e improvvisamente abbiamo tonnellate di spazio indietro!

— Nick

Finalmente una risposta che ha funzionato per me. PostgreSQL si era bloccato e aveva lasciato connessioni aperte a 400GiB (!!!) di file non collegati su un disco da 1 TB. Il riavvio di Postgres l'ha risolto.

— sudo,