Як звільнити використання Inode?

У мене є дисковий диск, де використання inode становить 100% (за допомогою df -iкоманди). Однак після значного видалення файлів використання залишається 100%.

Який правильний спосіб це зробити тоді?

Як можливо, що дисковий накопичувач із меншим обсягом дискового простору може мати більше використання Inode, ніж дисковий диск з більшим використанням дискового простору?

Чи можливо, якщо я zip багато файлів, що зменшить кількість використаних inode?

На диску досить легко використовувати велику кількість входів, навіть якщо диск не дуже заповнений.

У файлі виділяється inode, тому якщо у вас є газильйони файлів, усі по 1 байті кожен, у вас буде не вистачати вкладень задовго до того, як у вас закінчиться диск.

Можливо також, що видалення файлів не зменшить кількість входів, якщо файли мають декілька жорстких посилань. Як я вже казав, вставки належать до файлу, а не до каталогу. Якщо у файлі є дві пов'язані з ним записи каталогів, видалення одного не вивільнить inode.

Крім того, ви можете видалити запис каталогу, але якщо запущений процес все ще має відкритий файл, вклад не буде звільнений.

Моя початкова порада полягатиме в тому, щоб видалити всі файли, які ви можете, а потім перезавантажте вікно, щоб переконатися, що процеси не залишаються відкритими файли.

Якщо ви це зробите, і у вас все ще виникають проблеми, повідомте нас про це.

До речі, якщо ви шукаєте каталоги, що містять багато файлів, цей скрипт може допомогти:

#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$

Якщо вам дуже не пощастило, ви використали близько 100% усіх входів і не можете створити шипу. Ви можете перевірити це за допомогою df -ih.

Тоді ця команда bash може допомогти вам:

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

І так, це займе час, але ви можете знайти каталог з найбільшою кількістю файлів.

Моя ситуація полягала в тому, що я не мав місця та я вже видалив усе, що міг.

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

Я перебуваю на ubuntu 12.04LTS і не міг видалити старі ядра Linux, які займали близько 400 000 inode, тому що apt був зламаний через відсутній пакет. І я не зміг встановити новий пакет, тому що мені було не в місцях, тому я застряг.

Я закінчив видаленням декількох старих ядер Linux вручну, щоб звільнити близько 10 000 inode

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

Цього було достатньо, щоб потім дозволити мені встановити відсутній пакет і виправити своє вподобання

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

а потім видаліть решту старих ядер Linux за допомогою apt

$ sudo apt-get autoremove

зараз набагато краще

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

Моє рішення:

Спробуйте дізнатися, чи це проблема з inodes із:

df -ih

Спробуйте знайти кореневі папки з великою кількістю утворень:

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

Спробуйте знайти конкретні папки:

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

Якщо це заголовки Linux, спробуйте видалити найстарші за допомогою:

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

Особисто я перемістив їх у змонтовану папку (бо для мене остання команда не вдався) та встановив останню з:

sudo apt-get autoremove -f

Це вирішило мою проблему.

У мене була та сама проблема, яку виправили, видаливши сеанси каталогу з php

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

Це можливо, /var/lib/php5якщо ви використовуєте старішу версію php.

Відтворіть його з наступного дозволу

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

Дозвіл для каталогу на Debian за замовчуванням показано drwx-wx-wt(1733)

Ми пережили це в обліковому записі HostGator (який розміщує обмеження у всіх своїх хостингах) після спам-атаки. Він залишив величезну кількість записів черг в /root/.cpanel/comet. Якщо це сталося, і ви виявите, що у вас немає вільних вводів, ви можете запустити цю утиліту cpanel через оболонку:

/usr/local/cpanel/bin/purge_dead_comet_files

Ви можете використовувати RSYNC для видалення великої кількості файлів

rsync -a --delete blanktest/ test/

Створіть порожню папку з 0 файлами в ній, і команда синхронізує ваші тестові папки з великою кількістю файлів (я видалив майже 5 М файлів за допомогою цього методу).

Завдяки http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux

eaccelerator може спричинити проблему, оскільки він збирає PHP в блоки ... У мене ця проблема була з сервером Amazon AWS на сайті з великим навантаженням. Звільніть Inodes, видаливши кеш-пам'ять eaccelerator в / var / cache / eaccelerator, якщо проблеми й надалі не виникають.

rm -rf /var/cache/eaccelerator/*

(або будь-який ваш кеш-директор)

Нещодавно ми стикалися з подібною проблемою. Якщо процес посилається на видалений файл, Inode не буде випущений, тому вам потрібно перевірити lsof /, і вбити / перезапустити процес вивільнить узори.

Виправте мене, якщо тут помиляюся.

Як було сказано раніше, у файловій системі може не вистачати вводів, якщо є багато невеликих файлів. Я надав деякі засоби для пошуку каталогів, які містять тут більшість файлів .

Пізня відповідь: У моєму випадку це були мої файли сеансу під

/var/lib/php/sessions

які використовували Inodes.
Я навіть не зміг відкрити свій crontab або створити новий каталог, не кажучи вже про запуск операції видалення. Оскільки я використовую PHP, у нас є цей посібник, куди я скопіював код із прикладу 1 і встановив cronjob для виконання тієї частини коду.

<?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();
?>

Якщо вам цікаво, як мені вдалося відкрити свій crontab, тоді добре, я видалив деякі сеанси вручну через CLI.

Сподіваюсь, це допомагає!

ви могли бачити цю інформацію

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

На сьогоднішній день багато відповідей на це, і все вищезазначене здається конкретним. Я думаю, що ви будете в безпеці, використовуючи, statяк ви йдете далі, але в залежності від ОС, ви можете отримати деякі помилки вкладки на вас. Тому реалізація власної statфункціональності дзвінків за допомогою 64bitуникнення будь-яких проблем із переповненням виглядає досить сумісною.

Якщо ви використовуєте докер, видаліть усі зображення. Вони використовували багато місця…

Зупиніть усі контейнери

docker stop $(docker ps -a -q)

Видаліть усі контейнери

docker rm $(docker ps -a -q)

Видалити всі зображення

docker rmi $(docker images -q)

Мені працює