Jak uwolnić użycie i-węzła?

Jeśli masz bardzo pecha, użyłeś około 100% wszystkich i-węzłów i nie możesz utworzyć scipt. Możesz to sprawdzić za pomocą df -ih.

Wtedy to polecenie bash może Ci pomóc:

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

I tak, to zajmie trochę czasu, ale możesz zlokalizować katalog z największą ilością plików.

Moja sytuacja była taka, że nie miałem i-węzłów i już usunąłem wszystko, co mogłem.

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

Jestem na ubuntu 12.04 LTS i nie mogłem usunąć starych jąder Linuksa, które zajęły około 400 000 i-węzłów, ponieważ apt został uszkodzony z powodu braku pakietu. I nie mogłem zainstalować nowego pakietu, ponieważ nie miałem i-węzłów, więc utknąłem.

Skończyłem usuwając kilka starych jąder Linuksa ręcznie, aby uwolnić około 10,000 i-węzłów

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

To wystarczyło, aby wtedy pozwól mi zainstalować brakujący pakiet i naprawić mój apt

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

A następnie usuń resztę starych jąder Linuksa za pomocą apt

$ sudo apt-get autoremove

Teraz jest o wiele lepiej

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

Moje rozwiązanie:

Spróbuj znaleźć, czy jest to problem z i-węzłami:

df -ih

Spróbuj znaleźć foldery główne z dużą liczbą i-węzłów:

for i in /*; do echo $i; find $i |wc -l; done

Spróbuj znaleźć konkretne foldery:

for i in /src/*; do echo $i; find $i |wc -l; done

Jeśli to są nagłówki Linuksa, spróbuj usunąć najstarsze za pomocą:

sudo apt-get autoremove linux-headers-3.13.0-24

Osobiście przeniosłem je do zamontowanego folderu (bo dla mnie ostatnia komenda nie powiodła się) i zainstalowałem najnowsze z:

sudo apt-get autoremove -f

Miałem ten sam problem, naprawiłem go usuwając sesje katalogowe php

rm -rf /var/lib/php/sessions/

Może znajdować się pod /var/lib/php5, Jeśli używasz starszej wersji php.

Odtworzyć go z następującym pozwoleniem

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

Domyślnie uprawnienie katalogu na Debianie pokazało drwx-wx-wt (1733)

Doświadczyliśmy tego na koncie HostGator (który nakłada limity inode na cały swój hosting) po ataku spamowym. Pozostawił po sobie wiele rekordów kolejki w /root/.cpanel / comet. Jeśli tak się stanie i okaże się, że nie masz wolnych i-węzłów, możesz uruchomić to narzędzie cpanel przez powłokę:

/usr/local/cpanel/bin/purge_dead_comet_files

Możesz użyć RSYNC, aby usunąć dużą liczbę plików

rsync -a --delete blanktest/ test/

Utwórz folder blanktest z 0 plikami w nim i polecenie zsynchronizuje foldery testowe z dużą liczbą plików(usunąłem prawie 5M plików za pomocą tej metody).

Dzięki http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux

Późna odpowiedź: W moim przypadku były to moje pliki sesji pod

/var/lib/php/sessions

Które używały i-węzłów.
Nie byłem nawet w stanie otworzyć mojej crontab lub tworzenia nowego katalogu, nie mówiąc już o uruchomieniu operacji usuwania. Ponieważ używam PHP, mamy przewodnik , w którym skopiowałem kod z przykładu 1 i skonfigurowałem cronjob, aby wykonać tę część kodu.

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

Jeśli zastanawiasz się, jak udało mi się otworzyć mój crontab, to cóż, usunąłem niektóre sesje ręcznie przez CLI.

Eaccelerator może być przyczyną problemu, ponieważ kompiluje PHP do bloków...Miałem ten problem z serwerem AWS Amazon na stronie z dużym obciążeniem. Zwolnij i-węzły, usuwając pamięć podręczną eAccelerator w /var/cache / eaccelerator, jeśli nadal masz problemy.

rm -rf /var/cache/eaccelerator/*

(lub cokolwiek Twój katalog pamięci podręcznej)

Ostatnio napotkaliśmy podobny problem, w przypadku, gdy proces odnosi się do usuniętego pliku, i-węzeł nie zostanie zwolniony, więc musisz sprawdzić lsof / i kill/ restart proces zwolni i-węzły.

Popraw mnie, jeśli się mylę.

Jak wspomniano wcześniej, system plików może się wyczerpać, jeśli jest dużo małych plików. Podałem kilka sposobów, aby znaleźć katalogi, które zawierają większość plików tutaj .

W jednej z powyższych odpowiedzi zasugerowano, że sesje były przyczyną wyczerpania się i-węzłów i w naszym przypadku tak właśnie było. Aby dodać do tej odpowiedzi, chociaż proponuję sprawdzić php.pliku ini oraz zapewnić session.gc_probability = 1 również session.gc_divisor = 1000 i session.gc_maxlifetime = 1440. W naszym przypadku sesja.gc_probability było równe 0 i spowodowało ten problem.

Na Raspberry Pi miałem problem z /var/cache/fontconfig dir z dużą ilością plików. Usunięcie zajęło więcej niż godzinę. I couse rm -rf *.cache* podniesiony Argument list too long Błąd. Użyłem poniżej jednego

find . -name '*.cache*' | xargs rm -f

Możesz zobaczyć tę informację

for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t

Ten artykuł uratował mi dzień: https://bewilderedoctothorpe.net/2018/12/21/out-of-inodes/

find . -maxdepth 1 -type d | grep -v '^\.$' | xargs -n 1 -i{} find {} -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n

Jak dotąd wiele odpowiedzi na to pytanie i wszystkie powyższe wydają się konkretne. Myślę, że będziesz bezpieczny, używając stat, ale w zależności od systemu operacyjnego, możesz dostać błędy i-węzła. Implementacja własnej funkcji wywołania stat przy użyciu 64bit, aby uniknąć problemów z przepełnieniem, wydaje się dość kompatybilna.

Jeśli używasz Dockera, usuń wszystkie obrazy. Wykorzystali wiele przestrzeni....

Zatrzymaj wszystkie pojemniki

docker stop $(docker ps -a -q)

Usuń wszystkie kontenery

docker rm $(docker ps -a -q)

Usuń wszystkie obrazy

docker rmi $(docker images -q)

Działa dla mnie