Найдите, где inodes используются
После замены карты сетевого интерфейса, там останется старыми записями в /etc/udev/rules.d/70-persistent-net.rules.
Решение состоит в том, чтобы удалить строки, содержащие старые MAC-адреса в этом файле, в нашем случае было 3 строки, которые могли быть удалены, перезагрузка и бинго.
e1000e теперь правильно загружается снова: сети зафиксированы.
Благодаря: http://linuxadmin.com.pl/replacing-network-interface-card-nic-in-ebian5-os/
Я видел этот вопрос по stackoverflow, но мне не понравился ни один из ответы, и это действительно вопрос, который в любом случае должен быть здесь, на U&L.
Обычно индексный дескриптор используется для каждого файла в файловой системе. Таким образом, исчерпание inodes обычно означает, что у вас много маленьких файлов. Таким образом, действительно возникает вопрос: «В каком каталоге находится большое количество файлов?»
В этом случае файловая система, о которой мы заботимся, - это корневая файловая система / , поэтому мы можем использовать следующую команду :
find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
Будет выведен список всех каталогов файловой системы с префиксом количества файлов (и подкаталогов) в этом каталоге. Таким образом, каталог с наибольшим количеством файлов будет внизу.
В моем случае получается следующее:
1202 /usr/share/man/man1
2714 /usr/share/man/man3
2826 /var/lib/dpkg/info
306588 /var/spool/postfix/maildrop
Итак, в основном / var / spool / postfix / maildrop потребляет все inodes.
Обратите внимание, у этого ответа есть три предостережения, о которых я могу подумать. Он ничего не обрабатывает должным образом с символами новой строки в пути. Я знаю, что в моей файловой системе нет файлов с символами новой строки, и, поскольку это используется только для человеческого потребления, потенциальную проблему не стоит решать (и всегда можно заменить \ n на \ 0 и используйте sort -z выше). Он также не работает, если файлы разбросаны по большому количеству каталогов. Однако это маловероятно, поэтому я считаю риск приемлемым. Он также будет подсчитывать жесткие ссылки на один и тот же файл (поэтому используется только один индексный дескриптор) несколько раз.Опять же, вероятность ложных срабатываний маловероятна
. Основная причина, по которой мне не понравился ни один из ответов на вопрос stackoverflow, заключается в том, что все они пересекают границы файловой системы. Поскольку моя проблема была в корневой файловой системе, это означает, что она будет проходить через каждую подключенную файловую систему. Использование -xdev в командах поиска даже не сработает должным образом.
Например, наибольшее количество голосов получил следующий ответ:
for i in `find . -type d `; do echo `ls -a $i | wc -l` $i; done | sort -n
Если мы изменим его на
for i in `find . -xdev -type d `; do echo `ls -a $i | wc -l` $i; done | sort -n
, даже если / mnt / foo является маунтом, это также каталог в корневой файловой системе, поэтому он появится в find. -mount -type d , а затем он будет передан в ls -a $ i , который погрузится в монтирование.
find в моем ответе вместо этого перечисляет каталог каждого файла на монтировании. Итак, в основном с файловой структурой, такой как:
/foo/bar
/foo/baz
/pop/tart
, мы получаем
/foo
/foo
/pop
Так что нам просто нужно подсчитать количество повторяющихся строк.
Пример Проверка кодов устройства
В зависимости от вашего сетевого хранилища, оно может не предложить полностью функциональную команду [119743]df[119744]. Поэтому в этих случаях Вы можете прибегнуть к использованию [119745]tune2fs[119746] вместо:
schtasks /Create /SC DAILY /TN TestRun /TR "'C:\Program Files\Test\test.exe' 'C:\'"
Пересекая границы файловой системы
schtasks /Create /?
Пример
Скажем, у меня есть мой [119751]/home[119752] каталог для автоматического монтирования через разделяемые ресурсы NFS с моего сетевого хранилища, имя которого mulder.
Обратите внимание, что точка монтирования все еще считается локальной для системы.
Теперь, когда я инициирую [119753]find[119754]:
Он нашел [119755]/home[119756], но ни одного из автоматически монтируемых содержимого, потому что они находятся на другом устройстве! Типы файловых системВы можете использовать переключатель на [119757]find[119758], [119759]-fstype[119760] для управления тем, какие типы файловых систем [119761]find[119762] будет искать.
ПримерКакие файловые системы у меня есть? Таким образом, вы можете использовать это для управления пересечением:
только ext3
только nfsext3 & ext4
Чтобы перечислить подробное использование INODE для / , используйте следующую команду:
echo "Detailed Inode usage for: $(pwd)" ; for d in `find -maxdepth 1 -type d |cut -d\/ -f2 |grep -xv . |sort`; do c=$(find $d |wc -l) ; printf "$c\t\t- $d\n" ; done ; printf "Total: \t\t$(find $(pwd) | wc -l)\n"
Команда для поиска используемого inode:
for i in /*; do echo $i; find $i |wc -l | sort ; done
Это репост с здесь по просьбе автора:
du --inodes -S | sort -rh | sed -n \
'1,50{/^.\{71\}/s/^\(.\{30\}\).*\(.\{37\}\)$/\1...\2/;p}'
И если вы хотите остаться в той же файловой системе, сделайте следующее:
du --inodes -xS
Вот пример вывода:
15K /usr/share/man/man3
4.0K /usr/lib
3.6K /usr/bin
2.4K /usr/share/man/man1
1.9K /usr/share/fonts/75dpi
...
519 /usr/lib/python2.7/site-packages/bzrlib
516 /usr/include/KDE
498 /usr/include/qt/QtCore
487 /usr/lib/modules/3.13.6-2-MANJARO/build/include/config
484 /usr/src/linux-3.12.14-2-MANJARO/include/config
ТЕПЕРЬ С LS:
Несколько человек упомянули, что у них нет до-date coreutils, а опция --inodes для них недоступна. Итак, вот ls:
ls ~/test -AiR1U |
sed -rn '/^[./]/{h;n;};G;
s|^ *([0-9][0-9]*)[^0-9][^/]*([~./].*):|\1:\2|p' |
sort -t : -uk1.1,1n |
cut -d: -f2 | sort -V |
uniq -c |sort -rn | head -n10
Если вам интересно, суть утомительного фрагмента регулярного выражения заключается в замене имени файла в каждом из ls результаты рекурсивного поиска с именем каталога, в котором он был найден. Оттуда это просто вопрос сжатия повторяющихся номеров inode, затем подсчета повторяющихся имен каталогов и соответствующей сортировки.
Параметр -U особенно полезен при сортировке, поскольку он специально выполняет сортировку , а не , а вместо этого представляет список каталогов в исходном порядке - или, другими словами, по номер inode .
И, конечно же, -1 невероятно полезен тем, что обеспечивает единый результат для каждой строки, независимо от возможных включенных символов новой строки в именах файлов или других чрезвычайно неприятных проблем, которые могут возникнуть при попытке проанализировать список.
И, конечно же, -A для всех и -i для индексного дескриптора и -R для рекурсивного типа, и это вкратце.
Основной метод заключается в том, что я заменяю каждое имя файла ls на имя содержащего его каталога в sed. После этого ... Ну, я и сам немного нечеткий.Я почти уверен, что он точно считает файлы, как вы можете видеть здесь:
% _ls_i ~/test
> 100 /home/mikeserv/test/realdir
> 2 /home/mikeserv/test
> 1 /home/mikeserv/test/linkdir
Это дает мне почти идентичные результаты с командой du :
DU:
15K /usr/share/man/man3
4.0K /usr/lib
3.6K /usr/bin
2.4K /usr/share/man/man1
1.9K /usr/share/fonts/75dpi
1.9K /usr/share/fonts/100dpi
1.9K /usr/share/doc/arch-wiki-markdown
1.6K /usr/share/fonts/TTF
1.6K /usr/share/dolphin-emu/sys/GameSettings
1.6K /usr/share/doc/efl/html
LS:
14686 /usr/share/man/man3:
4322 /usr/lib:
3653 /usr/bin:
2457 /usr/share/man/man1:
1897 /usr/share/fonts/100dpi:
1897 /usr/share/fonts/75dpi:
1890 /usr/share/doc/arch-wiki-markdown:
1613 /usr/include:
1575 /usr/share/doc/efl/html:
1556 /usr/share/dolphin-emu/sys/GameSettings:
Я думаю, что include просто зависит от того, какой каталог программа просматривает в первую очередь - потому что это одни и те же файлы и жестко связаны. Вроде как то, что выше. Хотя я могу ошибаться - и приветствую исправление ...
DU DEMO
% du --version
> du (GNU coreutils) 8.22
Создайте тестовый каталог:
% mkdir ~/test ; cd ~/test
% du --inodes -S
> 1 .
Некоторые дочерние каталоги:
% mkdir ./realdir ./linkdir
% du --inodes -S
> 1 ./realdir
> 1 ./linkdir
> 1 .
Создайте несколько файлов:
% printf 'touch ./realdir/file%s\n' `seq 1 100` | . /dev/stdin
% du --inodes -S
> 101 ./realdir
> 1 ./linkdir
> 1 .
Некоторые жесткие ссылки:
% printf 'n="%s" ; ln ./realdir/file$n ./linkdir/link$n\n' `seq 1 100` |
. /dev/stdin
% du --inodes -S
> 101 ./realdir
> 1 ./linkdir
> 1 .
Посмотрите на жесткие ссылки:
% cd ./linkdir
% du --inodes -S
> 101
% cd ../realdir
% du --inodes -S
> 101
Они подсчитываются отдельно, но переходите на один каталог вверх ...
% cd ..
% du --inodes -S
> 101 ./realdir
> 1 ./linkdir
> 1 .
Затем я запустил свой запускаемый скрипт снизу и:
> 100 /home/mikeserv/test/realdir
> 100 /home/mikeserv/test/linkdir
> 2 /home/mikeserv/test
И скрипт Грэма:
> 101 ./realdir
> 101 ./linkdir
> 3 ./
Итак, я думаю, что это показывает что единственный способ подсчитать индексные дескрипторы - это индексные дескрипторы. А поскольку подсчет файлов означает подсчет inodes, вы не можете подсчитать inodes дважды - для точного подсчета файлов inodes не могут быть подсчитаны более одного раза.
Однозначный ответ с максимальным количеством голосов помогает понять концепцию индексных дескрипторов в linux и unix, однако на самом деле это не помогает, когда дело доходит до решения реальной проблемы удаления или удаление inodes с диска. Более простой способ сделать это в системах на основе Ubuntu - удалить ненужные заголовки и изображения ядра Linux.
sudo apt-get autoremove
Сделал бы это за вас. В моем случае использование inodes было на уровне 78%, из-за чего я получил предупреждение.
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 524288 407957 116331 78% /
none 957443 2 957441 1% /sys/fs/cgroup
udev 956205 388 955817 1% /dev
tmpfs 957443 320 957123 1% /run
none 957443 1 957442 1% /run/lock
none 957443 1 957442 1% /run/shm
none 957443 5 957438 1% /run/user
После выполнения команды sudo apt-get autoremove он снизился до 29%
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 524288 150472 373816 29% /
none 957443 2 957441 1% /sys/fs/cgroup
udev 956205 388 955817 1% /dev
tmpfs 957443 320 957123 1% /run
none 957443 1 957442 1% /run/lock
none 957443 1 957442 1% /run/shm
none 957443 5 957438 1% /run/user
Это было мое наблюдение, которое сэкономило мне время. Люди могут найти лучшее решение, чем это.
Я считаю, что быстрее и проще выполнять детализацию с помощью следующей команды:
$ sudo du -s --inodes * | sort -rn
170202 var
157325 opt
103134 usr
53383 tmp
<snip>
Затем вы можете зайти, например, в varи посмотреть, какие там большие индексные дескрипторы, использующие каталоги.
До сих пор все ответы предполагали, что проблема заключается в том, что множество файлов находится в одном каталоге, а не во многих подкаталогах, которые способствуют возникновению проблемы. К счастью, решение состоит в том, чтобы просто использовать меньше флагов.
# du --inodes --one-file-system /var | sort --numeric-sort
...
2265 /var/cache/salt/minion
3818 /var/lib/dpkg/info
3910 /var/lib/dpkg
4000 /var/cache/salt/master/gitfs/refs
4489 /var/lib
5709 /var/cache/salt/master/gitfs/hash
12954 /var/cache/salt/master/gitfs
225058 /var/cache/salt/master/jobs
241678 /var/cache/salt/master
243944 /var/cache/salt
244078 /var/cache
248949 /var
Или с более короткими вариантами:du --inodes -x /var | sort -n. К сожалению, не все версии duимеют опцию inodes.