Wykorzystanie miejsca na dysku nie sumuje się z df & du

Próbuję zwolnić trochę miejsca na dysku - jeśli to zrobię df -h, mam system plików o nazwie / dev / mapper / vg00-var, który mówi, że jest to 4G, 3,8G, pozostało 205M.

To odpowiada mojemu katalogowi / var.

Jeśli du -kscxh *zejdę do / var i zrobię , suma to 2.1G

2.1G + 200M za darmo = 2.3G ... Więc moje pytanie brzmi, gdzie jest pozostałe 1,7G?

linux du df

— Codecraft
źródło

Co du -shx /varmówi

— Kyle Smith

Możesz także usunąć pliki z otwartymi uchwytami plików. System operacyjny nie zwolni miejsca, dopóki uchwyty nie zostaną zamknięte, ale nie zobaczysz ich za pomocą „du”. Możesz uruchomić „lsof / var | grep usunięty” (lub coś podobnego), aby je zobaczyć. W rzeczywistości nie byłoby to zaskakujące odkrycie, powiedzmy, / var / log, jeśli dzienniki są obracane, ale proces rejestrowania nie jest poprawnie przeprowadzony przez HUP.

— cjc

Usuwałem niektóre pliki dziennika, które oszalały, wydawało się, że się nie obracają, ale w każdym razie miałem jedno słowo e-maila od znajomego „restartu” - pomyślałem, że jest sarkastyczny, ale najwyraźniej nie :) Znalazłem moje miejsce na dysku ... katastrofa została (na razie powstrzymana).

— Kodekraft

@Codecraft Tak, ponowne uruchomienie z pewnością wyczyści wszystkie otwarte uchwyty plików, chociaż to trochę jak pękanie jajka młotkiem.

— cjc

@cjc, o ile dostanę żółtej dobroci ...! Wszelkie sugestie dotyczące sposobu usuwania otwartych uchwytów do plików bez wbijania jajka?

— Kodekraft

Prawdopodobnie masz jakiś usunięty duży plik dziennika, plik bazy danych lub coś podobnego leżącego wokół, czekającego na proces wstrzymujący jego zwolnienie.

W systemie Linux usunięcie pliku po prostu rozłącza plik. W rzeczywistości jest usuwany, gdy do tego pliku nie są już podłączone żadne uchwyty plików. Tak więc, jeśli masz plik dziennika 2 GB, który usuwasz ręcznie za pomocą rm, miejsce na dysku nie zostanie zwolnione, dopóki nie zrestartujesz demona syslog (lub wyślesz HUPdo niego sygnał).

Próbować

lsof -n | grep -i deleted

i sprawdź, czy nadal masz jakieś usunięte pliki zombie.

— Janne Pikkarainen
źródło

Nie dostałem się do uruchomienia twojego polecenia, ale to, co powiedziałeś, wyglądało na uderzające - ręcznie zabijałem niektóre dzienniki - zwariowane, a w końcu ponowne uruchomienie spowodowało ponowne obliczenie miejsca na dysku i prawidłowe wyświetlenie.

— Kodekraft

Pracowało dla nas z logami Apache wypełniającymi katalog / var / log / apache /. Może więc nie być konieczne ponowne uruchomienie całego serwera ani syslog, tylko usługa, którą znajdziesz w wynikach powyższego polecenia.

— Yvan

Właśnie to mieliśmy. Mieliśmy tomcat6 catalina.out, który nie został złapany przez logrotate, czy usunęliśmy go, gdy osiągnął 4 Gb i naprawiliśmy logrotate. Kilka tygodni później zastanawialiśmy się, dlaczego 4Gb nie wróciło. To lsofpolecenie pokazało, że mamy wiele plików tomcat oczekujących na usunięcie. Ponowne uruchomienie tomcat i nagle mamy mnóstwo miejsca z powrotem!

— Nick

Wreszcie odpowiedź, która zadziałała dla mnie. PostgreSQL zawiesił się i pozostawił otwarte połączenia z 400GiB (!!!) niepowiązanych plików na dysku 1TiB. Ponowne uruchomienie Postgres naprawiło to.

— sudo