Jestem w dużej mierze na serwerach EC2 Amazon. Uruchamiam polecenie df i otrzymuję:
root@db:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.9G 9.1G 284M 98% /
tmpfs 3.8G 0 3.8G 0% /lib/init/rw
varrun 3.8G 116K 3.8G 1% /var/run
varlock 3.8G 0 3.8G 0% /var/lock
udev 3.8G 80K 3.8G 1% /dev
tmpfs 3.8G 0 3.8G 0% /dev/shm
/dev/sdb 414G 957M 392G 1% /mnt
/dev/sdf 50G 12G 35G 26% /byp
/dev/sdk 99G 31G 63G 33% /backups
Następnie uruchamiam polecenie du i otrzymuję:
root@db:/# du -s -h /*
31G /backups
5.5M /bin
136K /boot
12G /byp
80K /dev
5.8M /etc
12K /home
70M /lib
11M /lib32
0 /lib64
16K /lost+found
759M /mnt
4.0K /opt
du: cannot access `/proc/6917/task/6917/fd/4': No such file or directory
du: cannot access `/proc/6917/fd/4': No such file or directory
0 /proc
31M /root
7.7M /sbin
4.0K /selinux
4.0K /srv
0 /sys
11M /tmp
1.1G /usr
114M /var
Jeśli zauważysz, że po zsumowaniu wszystkich rozmiarów danych wyjściowych polecenia du z nie zamontowanych katalogów, nie uzyskasz wartości zbliżonej do 9,1 G, jak widać w poleceniu df.
Czy to oznacza, że mam zły dysk? Jeśli tak, jak mogę to naprawić?
źródło
lsof +L1
może czasem działać lepiej niż ten grep ...Istnieje wiele powodów, dla których du nie jest równy df. Zobacz odpowiedzi na to pytanie .
Niektóre z nich to nakładki nakładek, wiele małych plików i większy rozmiar bloku oraz usunięte pliki, które są nadal w użyciu. Montowania nakładkowe mają miejsce, gdy system plików został zamontowany w punkcie montowania, w którym były pliki, więc du ich nie widzi.
Główną różnicą między nimi jest to, że df po prostu sprawdza superblok i ufa mu, gdzie jako du skanuje wszystkie pliki, które jest w stanie zobaczyć, i dodaje je. Zobacz ten link IBM, aby uzyskać informacje na temat superbloku.
źródło
Zawsze używaj opcji -x z du, gdy gonisz za takimi problemami. Chroni du przed przekraczaniem systemów plików.
źródło