Co zjada moje miejsce na dysku?

Używam Nadii Linux Mint 14. Partycja Linux ma 10G. Po uruchomieniu systemu duzgłasza 80% użycia. Następnie użycie powoli rośnie, aż osiągnie 100%, a system stanie się bezużyteczny. (Może się to zdarzyć w kolejności dni lub tygodni). Po ponownym uruchomieniu użycie resetuje się do 80%.

Najdziwniejsze jest to, że dunie wykazuje zmian.

Oto wyniki tych poleceń (Windows i partycje dysku zewnętrznego są elided):

# --- Just after reboot ---

$ df -h     
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  7.3G  2.0G  80% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M  288K  437M   1% /run/shm
none            100M   12K  100M   1% /run/user

$ sudo du -x   -d1 -h /
186M    /opt
512M    /var
11M /sbin
556K    /root
1.3G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
60K /tmp
9.1M    /bin
4.0K    /srv
7.3G    /            # <-- note this


# --- After some time ---

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  9.1G  199M  98% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M   27M  411M   7% /run/shm
none            100M   28K  100M   1% /run/user

$  sudo du -x   -d1 -h /
186M    /opt
511M    /var
11M /sbin
556K    /root
1.4G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
520K    /tmp
9.1M    /bin
4.0K    /srv
7.3G    /              # <-- note this

(Uwaga: używam hibernacji. Po hibernacji użycie pozostaje takie samo, a po ponownym uruchomieniu resetuje się do 80%.)

Jak mogę śledzić, co zjada przestrzeń?

Przeczytałem to pytanie . Nadal jestem w ciemności. Jak dowiedzieć się, który program jest odpowiedzialny za to zachowanie?

Po edycji : znalazłem. Miejsce jest zajęte przez dziennik jądra, który jest widoczny przez dmesg. Zapełnia się, ponieważ moja maszyna generuje błędy w tempie 5 na sekundę. (Jest to związane z tym błędem .) Pozwól przyszłym czytelnikom z podobnym problemem - wolno zapełniającym się niewidocznym miejscem na dysku du- nie zapomnij spróbować dmesgposzukać przyczyny.

Powtarzające się wykonanie

sudo du -x   -d1 -h /

(w dół drzewa katalogów) powinien ci powiedzieć, gdzie miejsce jest zajęte. To prawdopodobnie wyjaśnia bez dalszego badania, która aplikacja to powoduje.

niewidoczne pliki

Jeśli dunie pokazuje tych plików, jedną z możliwości są pliki usunięte. Plik (a raczej: jego nazwa, tzn. Wpis w katalogu) można usunąć, gdy plik jest nadal w użyciu. Dopóki istnieje prawidłowy deskryptor pliku wskazujący na ten plik, zajmuje on miejsce na woluminie (jeśli nie jest to pusty plik ...).

cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0

Możesz znaleźć te pliki za pomocą find:

find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n     %l\n' 2>/dev/null

Może to być jeden pojedynczy duży plik lub kilka mniejszych plików, które powodują problem. W moim systemie jest teraz około 30 takich plików (należących tylko do pięciu procesów). ls -lpokazuje rozmiar tych plików, ale wydaje się, że nie można uzyskać tej wartości find.

Po zabiciu procesu przestrzeń ponownie staje się dostępna dla systemu plików ( df).

Użyj czegoś takiego

lsof -s | grep deleted | sort -k 8

aby zobaczyć, które procesy utrzymują usunięte pliki otwarte. Ważnymi polami są drugi (PID) i ósmy (trzeci od ostatniego; rozmiar pliku).

(Zwróć uwagę na powielone linie, nie licz ich dwa razy. Sprawdź PID i ścieżkę pliku (ostatnie pole) lub numer i-węzła (drugie do ostatniego pola).)

Następnie, jeśli znajdziesz proces, który prawdopodobnie jest winowajcą, możemy zobaczyć, jak go naprawić.

find / -size +10000k -print0 | xargs -0 ls -l -h

Użyj tego, aby znaleźć rekurencyjnie to, co wypełnia ponad 10 MB + z /(root), i wyświetl to z dużą ilością szczegółów ls -lw xargs. Jeśli napiszesz 1000000 (2 dodatkowe zera), możesz na przykład uzyskać 1 GB +.

du / -h --max-depth=1 | sort -h

Możesz także użyć du i po prostu wkopać go ręcznie.

Ilekroć tak się dzieje, zawsze zaczynam koncentrować się na określonych podkatalogach. Mając to na uwadze, opracowano strukturę FHS, której przestrzega większość dystrybucji Linuksa.

Najpierw zajrzyj /var, a następnie /home.

$ sudo du -x -d1 -h /var  | sort -hr`

$ sudo du -x -d1 -h /home | sort -hr`

Możesz zawęzić obszar zainteresowania do podkatalogów również w jednej z tych lokalizacji. Kiedy już skończyłeś szukać, zwykle przechodzę do /root, a na końcu pozostałych podkatalogów /.

Jeśli jest to dystrybucja oparta na systemie Red Hat, pamięć podręczna yumużywana do przeprowadzania aktualizacji może zajmować dużo miejsca. Możesz użyć tego polecenia, aby je wyczyścić:

$ yum clean packages

Inne dystrybucje że stosowanie aptmoże zrobić coś podobnego apt-get clean.

Uruchomiłbym również to polecenie u góry /katalogu, ta lokalizacja może czasem stać się źródłem zbłąkanych plików dziennika.

$ ls -la /

Zwróć szczególną uwagę na pliki kropek! Rzeczy nazwane .blahna przykład.

timeshift jadłem mój dysk.

sudo timeshift -delete--all

Odzyskano 50 Gb.

Mam prawie taką samą sytuację.

W moim przypadku powodem było VMware. Jeden z pozostałych VMwares na tym samym komputerze, zajmował miejsca na dysku. Dlatego moje użycie miejsca na dysku wyniosło 100%.

Po usunięciu dużych plików z VMware sąsiada działa poprawnie.