Dysk pełny, du mówi inaczej. Jak dalej badać?

Mam dysk SCSI na serwerze (sprzętowy Raid 1), 32G, ext3 system plików. dfmówi mi, że dysk jest w 100% pełny. Jeśli usunę 1G, zostanie to poprawnie pokazane.

Jednak jeśli uruchomię a, du -h -x /to dupowie mi, że używane są tylko 12G (używam z -xpowodu niektórych mocowań Samby).

Więc moje pytanie nie dotyczy subtelnych różnic między poleceniami du i df, ale o to, jak mogę dowiedzieć się, co powoduje tę ogromną różnicę?

Uruchomiłem ponownie komputer w celu sprawdzenia, czy błąd fsck nie powiódł się. Powinienem biec badblocks? lsofpokazuje mi brak otwartych usuniętych plików, lost+foundjest pusty i nie ma oczywistej instrukcji warn / err / fail w pliku wiadomości.

Zapytaj o dalsze szczegóły dotyczące konfiguracji.

Sprawdź pliki w punktach montowania. Często, gdy montujesz katalog (powiedzmy sambafs) w systemie plików, który już zawierał plik lub katalogi, tracisz możliwość zobaczenia tych plików, ale wciąż zajmują one miejsce na dysku bazowym. Miałem kopie plików w trybie pojedynczego użytkownika zrzucam pliki do katalogów, których nie widziałem poza trybem pojedynczego użytkownika (ze względu na zamontowanie na nich innych systemów katalogowych).

Natknąłem się na tę stronę, próbując wyśledzić problem na lokalnym serwerze.

W moim przypadku df -hi du -shniedopasowane o około 50% wielkości dysku twardego.

Było to spowodowane tym, że apache (httpd) przechowuje w pamięci duże pliki dziennika, które zostały usunięte z dysku.

To było śledzone przez uruchomiony lsof | grep "/var" | grep deletedgdzie /varbyła partycja Musiałem posprzątać.

Dane wyjściowe pokazały następujące wiersze:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Sytuacja została następnie rozwiązana przez ponowne uruchomienie apache ( service httpd restart) i wyczyściła 2 GB miejsca na dysku, umożliwiając usunięcie blokad usuniętych plików.

Zgadzam się z odpowiedzią OldTroll jako najbardziej prawdopodobną przyczyną twojego „brakującego” miejsca.

W systemie Linux możesz z łatwością ponownie zainstalować całą partycję główną (lub dowolną inną partycję) w innym miejscu w systemie plików, np. / Mnt, po prostu wydaj

mount -o bind / /mnt

wtedy możesz zrobić

du -h /mnt

i zobacz, co zajmuje twoją przestrzeń.

Ps: Przepraszam, że dodałem nową odpowiedź, a nie komentarz, ale potrzebowałem trochę formatowania, aby ten post był czytelny.

Zobacz co df -imówi. Możliwe, że brakuje Ci i-węzłów, co może się zdarzyć, jeśli w tym systemie plików znajduje się duża liczba małych plików, które zużyją wszystkie dostępne i-węzły bez zajmowania całej dostępnej przestrzeni.

W moim przypadku miało to związek z dużymi usuniętymi plikami. Rozwiązanie problemu było dość bolesne, zanim znalazłem tę stronę, co ustawiło mnie na właściwej ścieżce.

W końcu rozwiązałem problem za pomocą lsof | grep deleted, który pokazał mi, który program przechowuje dwa bardzo duże pliki dziennika (łącznie 5 GB mojej dostępnej partycji głównej 8 GB).

Pliki, które są otwierane przez program, tak naprawdę nie znikają (przestają zajmować miejsce na dysku) po ich usunięciu, a znikają, gdy program je zamyka. Program może mieć ogromny plik tymczasowy, którego ty (i du) nie widzisz. Jeśli jest to program zombie, może być konieczne ponowne uruchomienie komputera w celu wyczyszczenia tych plików.

Spróbuj tego, aby sprawdzić, czy martwy / zawieszony proces jest zablokowany podczas zapisywania na dysku: lsof | grep "/ mnt"

Następnie spróbuj zabić wszystkie zablokowane PID-y (szczególnie poszukaj linii kończących się na „(usunięte”))

To najłatwiejsza metoda, jaką do tej pory znalazłem, aby znaleźć duże pliki!

Oto przykład, jeśli twoje rootowanie jest pełne / (mount / root) Przykład:

cd / (więc jesteś rootem)

ls | xargs du -hs

Przykładowe dane wyjściowe:

 Pojemnik 9,4 mln
 Rozruch 63M
 Grupa 4,0 tys
 Dev. 680 tys
 31 mln itp
 Dom 6.3G
 313 mln lib
 32M lib64
 16K utracone + znaleziono
 Media 61G
 4,0 tys
 113M opt
 du: nie można uzyskać dostępu do `proc / 6102 / task / 6102 / fd / 4 ': Brak takiego pliku lub katalogu
 0 proc
 Korzeń 19M
 Bieg 840 K.
 19 mln sbin
 4.0K selinux
 4.0K srv
 Sklep 25G
 26 mln tmp

wtedy zauważysz, że sklep jest duży, zrób cd / store

i biegnij ponownie

ls | xargs du -hs

Przykładowe dane wyjściowe: 
 Kopia zapasowa 109M
 358 mln fnb
 4.0G iso
 8,0 tys. Ks
 16K utracone + znaleziono
 Korzeń 47M
 Skrypty 11 mln
 79 mln tmp
 21G vms

w tym przypadku katalog vms jest spacją.

Dla mnie musiałem działać, sudo duponieważ pod okiem było wiele plików dokerów /var/lib/docker, a użytkownik inny niż sudo nie ma uprawnień do odczytu.

Jeszcze jedna możliwość do rozważenia - masz prawie całkowitą rozbieżność, jeśli używasz Dockera i uruchamiasz df / du w kontenerze, który używa montowania woluminów. W przypadku katalogu podłączonego do woluminu na hoście dokera, df zgłosi sumy df HOST. Jest to oczywiste, jeśli się nad tym zastanowić, ale gdy pojawi się raport o „niekontrolowanym pojemniku wypełniającym dysk!”, Upewnij się, że zweryfikowałeś zużycie przestrzeni plików w pojemniku za pomocą czegoś podobnego du -hs <dir>.

Miałem ten problem również w Centos 7 i znalazłem rozwiązanie po wypróbowaniu wielu rzeczy, takich jak bleachbit i cleaning / usr i / var, mimo że pokazywały tylko około 7G każdy. Wciąż wyświetlał 50G 50G używanych na partycji głównej, ale pokazywał tylko 9G użycia pliku. Uruchomiłem live Ubuntu CD i odmontowałem naruszającą partycję 50G, otworzyłem terminal i uruchomiłem xfs_check i xfs_repair na partycji. Następnie ponownie zamontowałem partycję, a mój utracony + znaleziony katalog został rozszerzony do 40G. Posortowałem utracone + znalezione według rozmiaru i znalazłem tekstowy dziennik tekstowy 38G dla Steam, który ostatecznie powtórzył błąd mp3. Usunąłem duży plik i teraz mam miejsce, a użycie moich dysków zgadza się z rozmiarem mojej partycji głównej. Nadal chciałbym wiedzieć, jak sprawić, by dziennik pary nie urósł już tak bardzo.

jeśli podłączony dysk jest folderem współdzielonym na komputerze z systemem Windows, to wygląda na to, że df pokaże rozmiar i użycie dysku całego dysku z systemem Windows, ale du pokaże tylko część dysku, do której masz dostęp. (i jest zamontowany). więc w takim przypadku problem musi zostać rozwiązany na komputerze z systemem Windows.

Podobna sytuacja przydarzyła nam się w produkcji - użycie dysku spadło do 98%. Czy następujące dochodzenie:

a) w df -icelu sprawdzenia użycia i-węzła zużycie i-węzła wyniosło 6%, więc niewiele mniejszych plików

b) Montowanie rooti sprawdzanie ukrytych plików. Nie można złożyć żadnych dodatkowych plików. duwyniki były takie same jak przed zamontowaniem.

c) Na koniec sprawdzone nginxlogi. Został skonfigurowany do zapisu na dysk, ale programista usunął plik dziennika bezpośrednio, powodując nginxprzechowywanie wszystkich dzienników w pamięci. Ponieważ plik /var/log/nginx/access.logzostał usunięty z dysku przy użyciu, rmnie był widoczny przy użyciu, duale plik był uzyskiwany przez nginxi dlatego nadal był otwarty

Miałem ten sam problem, o którym mowa w tym temacie, ale w jednym VPS. Przetestowałem więc wszystko, co opisano w tym temacie, ale bez powodzenia. Rozwiązaniem było skontaktowanie się z pomocą techniczną z naszym dostawcą VPS, który dokonał ponownego obliczenia przydziału i skorygował różnicę przestrzeni między df -hi du-sh /.

Dzisiaj napotkałem ten problem na urządzeniu FreeBSD. Problem polegał na tym, że był to artefakt vi(nie vim, nie jestem pewien, czy vimstworzy ten problem). Plik zajmował miejsce, ale nie został w pełni zapisany na dysku.

Możesz to sprawdzić za pomocą:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Spogląda na wszystkie otwarte pliki i sortuje (numerycznie przez -n) według 8. kolumny (klucz, -k8), pokazując dziesięć ostatnich pozycji.

W moim przypadku ostatni (największy) wpis wyglądał tak:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Oznaczało to, że proces (PID) 12345 zużywał 1,46G (ósma kolumna podzielona przez 1024³) dysku pomimo braku jego duzauważenia. vijest okropny podczas oglądania bardzo dużych plików; nawet 100 MB jest na to duży. 1,5 G (lub jak duży był ten plik) jest niedorzeczne.

Rozwiązaniem było sudo kill -HUP 12345(jeśli to nie zadziała, ja sudo kill 12345i jeśli to też się nie powiedzie, to przerażające kill -9wejdą do gry).

Unikaj edytorów tekstu na dużych plikach. Przykładowe obejścia dla szybkiego przeglądania:

Zakładając rozsądne długości linii:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Zakładając nieuzasadnione duże linie:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Są użycie vim -Rzamiast viewpoznieważ vimjest prawie zawsze lepiej ... gdy jest zainstalowany. Zapraszam do włożenia ich do viewlub vi -Rzamiast.

Jeśli otwierasz tak duży plik, aby go faktycznie edytować, rozważ sedlub awkinne podejście programowe.

sprawdź, czy na serwerze jest zainstalowany agent ossec. Lub niektóre procesy używają usuniętych plików dziennika. Kiedyś byłem agentem ossec.

sprawdź / lost + found, miałem system (centos 7), a część pliku w / lost + found zjadła całą przestrzeń.