Как бесплатно использовать Inode?

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

Какой правильный способ сделать это тогда?

Как это возможно, что дисковод с меньшим использованием дискового пространства может иметь более высокое использование Inode, чем дисковод с более высоким использованием дискового пространства?

Возможно ли, если я заархивирую много файлов, это уменьшит количество используемых инодов?

Для диска довольно легко использовать большое количество inode, даже если диск не очень заполнен.

Inode выделяется для файла, поэтому, если у вас есть несколько миллиардов файлов, каждый по 1 байту, у вас закончатся inode задолго до того, как закончится диск.

Также возможно, что удаление файлов не уменьшит количество инодов, если файлы имеют несколько жестких ссылок. Как я уже сказал, 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

И да, это займет время, но вы можете найти каталог с наибольшим количеством файлов.

Моя ситуация состояла в том, что у меня не было inode, и я уже удалил все, что мог.

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

Я на Ubuntu 12.04LTS и не могу удалить старые ядра Linux, которые занимали около 400 000 Inode, потому что apt был сломан из-за отсутствующего пакета. И я не смог установить новый пакет, потому что у меня не было inode, поэтому я застрял.

В итоге я удалил несколько старых ядер 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% /

Мое решение:

Попробуйте найти, если это проблема с inode:

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 через shell:

/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 на сайте с большой нагрузкой. Освободите Inode, удалив кэш eaccelerator в / var / cache / eaccelerator, если у вас по-прежнему возникают проблемы.

rm -rf /var/cache/eaccelerator/*

(или какой-либо другой каталог кеша)

Недавно мы столкнулись с подобной проблемой. В случае, если процесс ссылается на удаленный файл, Inode не должен освобождаться, поэтому вам нужно проверить lsof /, и kill / restart процесса освободит inode.

Поправь меня, если я здесь не прав.

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

Поздний ответ: в моем случае это были мои файлы сессий под

/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мере продвижения, но в зависимости от ОС, вы можете получить некоторые ошибки inode. Таким образом, реализация ваших собственных statфункций вызова с использованием, 64bitчтобы избежать любых проблем переполнения, кажется довольно совместимой.

Если вы используете докер, удалите все изображения. Они использовали много места ....

Остановить все контейнеры

docker stop $(docker ps -a -q)

Удалить все контейнеры

docker rm $(docker ps -a -q)

Удалить все изображения

docker rmi $(docker images -q)

Работает для меня