Brak miejsca na dysku w systemie Linux

Mam pudełko Ubuntu z 30 GB miejsca na dysku, które jest prawie pełne:

df -h

Filesystem      Size  Used Avail Use% Mounted on 
/dev/vda1        30G  28G     0  100% /

Ale kiedy sprawdzam rozmiar wszystkich folderów głównych za pomocą

sudo du -sh /foldername

Dostaję tylko 17,2 GB

lib/        6.7G
usr/        4.8G
home/       2.0G
var/        1.3G
boot/       1.1G
swapfile    1.1G
root/       125M
sbin/       12M
bin/        11M
etc/        8M
run/        420K
lost+found/ 16K
media/      8.8K
dev/        4K
lib64/      4K
mnt/        4K
srv/        4K
opt/        4K
tmp/        4K
sys/        0
proc/       0

Czy coś tu wygląda podejrzanie? Około 11 gigabajtów nie zostało uwzględnionych. Gdzie może być brakująca 11G?

linux disk-space

— JannieT
źródło

Istnieje cała seria podobnych pytań na ten temat na temat SF, sugeruję najpierw spróbować przeczytać tam. Zaktualizuj pytanie z linkami do tego, co próbowałeś - to znaczy, jeśli nie znajdziesz rozwiązania. serverfault.com/q/275206/355160

— Marek Rost

Również nie uwzględniając miejsca pokazanego przez df i łańcuchów duplikatów wskazanych w komentarzach tam. Jaki jest typ systemu plików.

— Kamil Maciorowski

@Marek dzięki za pomocny wskaźnik. W przeszłości byłem ścigany przez społeczność SF za podobne pytania, więc nie spodziewałem się takiej odpowiedzi.

— JannieT

Czy sprawdziłeś już wyczerpanie i-węzła? Użyj df -i. Użyj również du -hxd 1 /podczas sprawdzania, gdzie poszło miejsce.

— Daniel B

Odpowiedzi:

Po otrzymaniu porady od społeczności zajmującej się błędami serwera sprawdziłem rozmiar bloku:

stat --printf='%s' -f .

co było „normalne” w 4096

Następnie sprawdziłem, ile usuniętych plików było nadal otwartych przez procesy:

lsof | grep -c DEL

które zgłosiło 143 pliki, które mogą odpowiadać za całą utraconą przestrzeń, ale myślę, że jest mało prawdopodobne

Następnie ponownie uruchomiłem pudełko i voila! Całe moje miejsce na dysku wróciło:

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            487M  4.0K  487M   1% /dev
tmpfs           100M  388K  100M   1% /run
/dev/vda1        30G   17G   12G  61% /

Odbicie

Fakt, że odzyskałem tak dużo miejsca na dysku po ponownym uruchomieniu, oznacza, że rozmiar bloku woluminu nie był głównym winowajcą. Więc nadal nie jestem w 100% pewien, co spowodowało rozbieżność, ale cieszę się, że odzyskałem moje miejsce!

— JannieT
źródło

„143 pliki, które mogą stanowić część utraconej przestrzeni, ale nie wszystkie” - skąd wiesz? Dlaczego nie wszystko?

— Kamil Maciorowski

@Kamil masz rację. Dziękuję Ci. Zaktualizowałem odpowiednio swój post.

— JannieT

Kiedyś miałem plik dziennika, który puchł ponad 20 GiB. Ponieważ ponowne uruchomienie zwolniło dla ciebie miejsce, myślę, że usunięte pliki będące przyczyną nie były tak mało prawdopodobne.

— Kamil Maciorowski

-1

Myślę, że możesz mieć duże ukryte pliki, które pojawią się tylko wtedy, gdy użyjesz -aflagi:

du -ha /foldername | sort -hr

Powyższe polecenie wyświetli rozmiar wszystkich plików (w tym plików ukrytych), a sortowanie uporządkuje je według rozmiaru, abyś mógł je zidentyfikować.

— AnythingIsFine
źródło

Pliki ukryte (nazwa pliku rozpoczynająca się od kropki) są oczywiście uwzględniane podczas korzystania du --summarizez folderu. --allpo prostu zmienia to, co dudrukuje.

— Daniel B

Bardzo przydatne polecenie.

— JannieT,

@DanielB: Dokładnie to, co powiedziałem „które pojawi się tylko, jeśli użyjesz flagi -a:”. JannieT napisał, że licząc rozmiar plików wymienionych w danych wyjściowych polecenia du, nie widział, gdzie jest brakujące miejsce. Jako taki zasugerowałem, żeby użył „-a”

— AnythingIsFine

Chodzi o to: zobaczysz to. Jest to suma folderu zawierającego pliki i wszystkie foldery nadrzędne. Po prostu nie będzie wyświetlał plików osobno. w żaden sposób --allnie zmienia sum .

— Daniel B

Nie powiedziałem też, że to zmieni sumy, pokaże tylko wszystkie pliki odpowiedzialne za zajmowanie miejsca. Niemniej jednak zredagowałem moją wstępną odpowiedź dla jasności. Dziękuję za twoją obserwację.

— AnythingIsFine