Nie sądzę, że „narzędzie do wizualizacji miejsca na dysku” może ci w tym pomóc: przestrzeń zajmowana i widoczna dla takich narzędzi jest taka sama dla du, tylko te narzędzia robią to bardziej szczegółowo. Ale narzędzie nadal zgłasza tylko te 8-10 GB, o których już wiesz, że są używane, a nie zgłasza, gdzie jest jeszcze dwadzieścia gigabajtów, których „brakuje w akcji”.
Możliwym wyjaśnieniem „znikającej” przestrzeni o takich proporcjach jest to, że znajduje się w jednym (lub więcej) usuniętych plikach .
Jeśli otworzysz plik w systemie Unix i podczas jego otwierania usuniesz go (odłączysz), będzie on nadal „istniał”, ale będzie widoczny tylko dla procesu posiadającego deskryptor pliku i natychmiast zniknie, gdy tylko proces się zakończy, zwalniając deskryptor.
To świetny sposób zarządzania plikami tymczasowymi.
Niestety, jeśli plik tymczasowy wycieka, a dane są do niego ciągle dodawane, bez zamykania i ponownego tworzenia pliku, wówczas dużo miejsca na dysku może „zniknąć”.
Jako root spróbuj:
ls -la /proc/*/fd/* | grep deleted
Nazwy plików i identyfikatory procesów podpowiedzą, które procesy zachowują „niepowiązane” miejsce.
Jeśli możesz to zrobić, oczywiście ponowne uruchomienie będzie miało ten sam efekt szybciej. Niektóre procesy są tak splecione w systemie, że lepiej zrestartować je, niż zakończyć i zarządzać wszystkimi innymi zależnymi procesami i usługami .
Na przykład na moim komputerze mam około 25 takich plików i ten
lrwx------ 1 root root 64 May 9 07:45 /proc/732/fd/8 -> /tmp/vmware-root/vmware-usbarb-732.log (deleted)
Wiem, że czasami rośnie w zakresie wielu megabajtów. Bieganie
vmware-usbarbitrator --kill
vmware-usbarbitrator
mogę zwolnić od zera do 100M miejsca, w zależności od tego, jak długo działało i ile wykorzystałem vmplayer.
Automatyzacja czeku
Sposobem sprawdzenia, które pliki zajmują miejsce, byłoby sprawdzenie ich rozmiarów: większość niepowiązanych plików ma tylko kilka bajtów.
Ta metoda wykorzystuje wc, co jest bardzo nieefektywne; prawdopodobnie otwieranie pliku, szukanie SEEK_ENDi zwracanie wartości ftell()byłoby znacznie, znacznie szybsze (szczególnie w przypadku dużych plików). Ale by to zrobić, trzeba skompilować małe narzędzie.
for i in $( ls -la /proc/*/fd/* 2>/dev/null \
| grep deleted \
| sed -e 's/.*\(\/proc\S*\) -.*/\1/g' ); do
wc -c $i | tr "\n" "="; readlink $i
done | grep -v "^0 " | sort -rn
Wykorzystuje (miejmy nadzieję) przenośny sposób wyświetlania listy wirtualnych plików wszystkich usuniętych plików i odczytuje je wc. Następnie dla każdego pliku odczytuje dowiązanie symboliczne. Pliki o zerowej długości są ignorowane, aby uniknąć bałaganu.
W moim świeżo uruchomionym systemie daje mi to
217032 /proc/812/fd/9=/var/run/nscd/dbMn7Auu (deleted)
217032 /proc/812/fd/8=/var/run/nscd/dbMn7Auu (deleted)
3278 /proc/2357/fd/3=/tmp/vmware-root/vmware-apploader-2327.log (deleted)
2257 /proc/2422/fd/7=/tmp/vmware-root/vmware-authdlauncher-2418.log (deleted)
więc wiem, że nscdkorzysta z 400 Kb „niewidocznej przestrzeni” (nie zmienia się to po ponownym uruchomieniu nscd; więc prawdopodobnie jest to obszar roboczy, który nie rośnie ... dużo. Nic nie powstrzymuje mnie przed kontrolowaniem procesu, chociaż).
Łatwo byłoby również zapisać powyższy kod w małym narzędziu i uruchomić go cron, odrzucając wszystkie wartości poniżej (powiedzmy) 500 megabajtów, ale wysyłając wiadomość e-mail do administratora, jeśli w końcu coś się pojawi.
duwyjściowych nie ma żadnych komunikatów o błędach : uruchamiasz to polecenie jakoroot, prawda ?!