2014-04-07 13:42:39 +0000 2014-04-07 13:42:39 +0000
26
26

Usuwanie plików, ale miejsce na dysku jest nadal pełne

Mam do czynienia ze starym CentOS 5.6 box, bez konfiguracji lvm, mój system plików root / jest pełny, wyczyściłem wiele starych plików dziennika i plików aplikacji, których nie potrzebuję, co było więcej niż 2 -5GB w rozmiarze, jednak mój system nadal zgłasza, że dysk jest pełny.

[root@tornms1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 130G 124G 0 100% /
/dev/sdb1 264G 188M 250G 1% /data
/dev/sda1 99M 24M 71M 26% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm

[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Jakiś pomysł co powinienem zrobić dalej? Niestety restart nie wchodzi w grę w tym momencie.

Odpowiedzi (9)

38
38
38
2014-04-07 14:02:13 +0000

Mogą się tu dziać dwie rzeczy.

Po pierwsze, twój system plików zarezerwował pewną przestrzeń, do której tylko root może zapisywać, aby krytyczne procesy systemowe nie przewracały się, gdy zwykłym użytkownikom zabraknie miejsca na dysku. To dlatego widzisz 124G z 130G używanych, ale zero dostępnych. Być może pliki, które usunąłeś obniżyły wykorzystanie do tego punktu, ale nie poniżej progu dla normalnych użytkowników.

Jeśli to jest twoja sytuacja i jesteś zdesperowany, możesz zmienić ilość miejsca zarezerwowanego dla root. Aby zmniejszyć ją do 1% (domyślnie jest to 5%), Twoje polecenie brzmiałoby

# tune2fs -m 1 /dev/sda3

Po drugie , system operacyjny nie zwolni miejsca na dysku dla usuniętych plików, które są nadal otwarte. Jeśli usunąłeś (powiedzmy) jeden z plików logów Apache'a, będziesz musiał zrestartować Apache'a, aby zwolnić miejsce na dysku.

18
18
18
2015-09-24 09:32:08 +0000

Jeśli usuniesz plik, który jest używany przez proces, nie możesz go już przeglądać przez ls. Proces nadal pisze do tego pliku, dopóki go nie zatrzymasz.

Aby zobaczyć te usunięte pliki, po prostu uruchomlsof|grep delete.

10
10
10
2014-04-07 21:03:43 +0000

2 inne sposoby na uzyskanie problemu dysk jest pełny:

1) ukryty pod punktem montowania: linux pokaże pełny dysk z plikami “ukrytymi” pod punktem montowania. Jeśli masz dane zapisane na dysku i zamontujesz na nim inny system plików, linux poprawnie odnotuje użycie dysku, nawet jeśli nie widzisz plików pod punktem montowania. Jeśli masz zamontowany system plików nfs, spróbuj go odmontować i sprawdzić, czy coś nie zostało przypadkowo zapisane w tych katalogach przed zamontowaniem.

2) zepsute pliki: Spotykam się z tym sporadycznie podczas transferu plików z Windowsa do linuksa przez SMB. Jeden plik nie zamyka deskryptora pliku i kończysz z 4GB plikiem śmieci.

To może być bardziej żmudne do naprawienia, ponieważ musisz znaleźć podkatalog, w którym znajduje się plik, ale jest łatwe do naprawienia, ponieważ sam plik jest łatwo usuwalny. Używam polecenia du i robię listę podkatalogów w katalogu głównym, aby dowiedzieć się, gdzie jest używane miejsce na pliki.

cd /
du -sh ./*

Liczba katalogów najwyższego poziomu jest zwykle ograniczona, więc ustawiam flagę czytelną dla człowieka -h, aby sprawdzić, który podkatalog zajmuje najwięcej miejsca.

Następnie przejdź do problematycznego dziecka i powtórz proces dla wszystkich znajdujących się w nim elementów. Aby ułatwić wykrycie dużych elementów, zmienimy nieco sposób działania du i połączymy go z sortowaniem.

cd /<suspiciously large dir>
du -s ./* | sort -n

co daje wynik od najmniejszego do największego według rozmiaru bajtu dla wszystkich plików i katalogów

4 ./bin 
462220 ./Documents
578899 ./Downloads
5788998769 ./Grocery List

Po zauważeniu zbyt dużego pliku, zazwyczaj można go po prostu usunąć.

4
4
4
2014-04-07 14:27:52 +0000

Możesz dowiedzieć się, które pliki są otwarte za pomocą lsof. Może on produkować dużo danych wyjściowych, więc ograniczyłem się w poniższym przykładzie do linii kończących się na log:

# lsof | grep log$
rsyslogd 2109 syslog 0u unix 0xffff88022fa230c0 0t0 8894 /dev/log
rsyslogd 2109 syslog 1w REG 252,6 62393 26 /var/log/syslog
rsyslogd 2109 syslog 2w REG 252,6 113725 122 /var/log/auth.log
rsyslogd 2109 syslog 3u unix 0xffff88022fa23740 0t0 8921 /var/spool/postfix/dev/log
rsyslogd 2109 syslog 5w REG 252,6 65624 106 /var/log/mail.log
/usr/sbin 2129 root 2w REG 252,6 93602 38 /var/log/munin/munin-node.log
/usr/sbin 2129 root 4w REG 252,6 93602 38 /var/log/munin/munin-node.log
...
1
1
1
2017-06-08 10:02:04 +0000

Jeśli niektóre pliki zostaną usunięte, ale nadal będą używane przez jakiś proces, to miejsce na nich nie zostanie zwolnione. W takim przypadku albo zrestartuj proces, który używa pliku, albo unieważnij plik. Jego zawsze dobrą praktyką, aby unieważnić takie pliki zamiast je usuwać. Aby znaleźć usunięte pliki, ale nadal są używane przez jakiś proces

#lsof +L1

poda on id procesu i deskryptor pliku. Aby unieważnić usunięty plik przez deskryptor pliku

#echo "" > /proc/$pid/fd/$fd
```.
1
1
1
2020-02-27 01:18:39 +0000

W większości przypadków, jeśli usuniemy jakiś plik dziennika, nie będzie on już widoczny przez ls. Proces nadal zapisuje do tego pliku, dopóki go nie zatrzymamy.

1
1
1
2017-10-31 13:45:06 +0000

Wpisz polecenie

#lsof +L1

Które pokaże listę plików, które trzymają pamięć z usuniętym cytatem.

Zwróć uwagę na pid (Process id) pliku

Zabij proces

#kill <pid>

Pamięć zostanie zwolniona przez proces

Sprawdź to komendą

#df -h
```.
0
0
0
2016-06-02 09:58:41 +0000

Rzeczywisty problem zaobserwowany na wolności:

Upewnij się, że usuwasz rzeczywiste pliki, a nie symlinki do plików. Może to dotyczyć zwłaszcza plików dziennika.

0
0
0
2016-01-23 08:00:36 +0000

Dodatkowo do tego, co zostało wyjaśnione, problem może być taki, że istnieje inny punkt montowania katalogu usuniętych plików na innym podłączonym urządzeniu dyskowym na tym samym serwerze. Sprawdź aktualne montowania i wpisy w fstab.