У меня есть диск, где использование inode составляет 100% (с помощью команды df -i).
Однако после удаления файлов существенно, использование остается на 100%.
Какой правильный способ сделать это?
Как возможно, что дисковый накопитель с меньшим объемом дискового пространства может иметь более высокий уровень использования Inode, чем дисковый накопитель с более высоким дисковым пространством?
Для диска довольно просто использовать большое количество используемых дескрипторов, даже если диск не очень заполнен.
Инод выделяется файлу, поэтому, если у вас есть gazillions файлов, каждый 1 байт каждый, вы закончите inodes задолго до того, как вы закончите с диска.
Также возможно, что удаление файлов не приведет к уменьшению количества индексных дескрипторов, если файлы имеют несколько жестких ссылок. Как я уже сказал, inodes принадлежат файлу, не запись в каталоге. Если у файла есть две записи каталога, связанные с ним, удаление одного из них не освободит индекс.
Кроме того, вы можете удалить запись в каталоге, но, если в запущенном процессе все еще открыт файл, inode не будет освобожден.
Моя первоначальная рекомендация заключалась бы в том, чтобы удалить все файлы, которые вы можете, а затем перезагрузите окно, чтобы убедиться, что процессы не оставлены, открывая файлы.
Если вы это сделаете, и у вас все еще есть проблема, сообщите нам.
Кстати, если вы ищете каталоги, содержащие много файлов, этот script может помочь:
#!/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
И да, это займет время, но вы можете найти каталог с наибольшим количеством файлов.
Моя ситуация была в том, что я был из inodes, и я уже удалился обо всем, что мог.
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 942080 507361 11 100% /
Я нахожусь на ubuntu 12.04LTS и не могу удалить старые ядра Linux, которые заняли около 400 000 инодов, потому что apt был сломан из-за недостающего пакета. И я не мог установить новый пакет, потому что я был из inodes, поэтому я застрял.
В итоге я удалил несколько старых ядер linux, чтобы освободить около 10 000 инодов.
$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*
Этого было достаточно, чтобы потом позволить мне установить недостающий пакет и исправить мой apt
$ 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)
eaccelerator может вызвать проблему, поскольку он компилирует PHP в блоки... У меня была эта проблема с сервером Amazon AWS на сайте с большой нагрузкой. Освободите Inodes, удалив кеш eaccelerator в /var/cache/eaccelerator, если у вас по-прежнему возникают проблемы.
rm -rf /var/cache/eaccelerator/*
(или независимо от вашего кеша)
Мы столкнулись с этим на учетной записи HostGator (кто размещает ограничения на использование inode на всех своих хостингах) после атаки спама. Он оставил огромное количество записей в очереди в /root/.cpanel/comet. Если это произойдет, и вы обнаружите, что у вас нет свободных инодов, вы можете запустить эту утилиту cpanel через оболочку:
/usr/local/cpanel/bin/purge_dead_comet_files
Мы столкнулись с аналогичной проблемой в последнее время. В случае, если процесс относится к удаленному файлу, Inode не освобождается, поэтому вам нужно проверить lsof/, а kill/restart процесс выведет inodes.
Исправьте меня, если здесь не так.
Вы можете использовать RSYNC для УДАЛЕНИЯ большого количества файлов
rsync -a --delete blanktest/ test/
Создайте пустую папку с 0 файлами в ней, и команда синхронизирует ваши тестовые папки с большим количеством файлов (я удалил почти 5M файлов с помощью этого метода).
Благодаря http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux
Как уже говорилось, файловая система может закончиться inodes, если есть много небольших файлов. Я предоставил некоторые средства для поиска каталогов, которые содержат большинство файлов здесь.
Многие ответы на этот вопрос до сих пор и все вышеизложенное кажутся конкретными. Я думаю, вы будете в безопасности, используя stat, пока вы идете вперед, но зависит от ОС, вы можете получить некоторые ошибки inode. Таким образом, реализация ваших собственных функций вызова stat с помощью 64bit, чтобы избежать проблем с переполнением, кажется довольно совместимой.
Почтовый каталог может быть заполнен файлами:
/главная/имя пользователя/Maildir/новый