Есть ли максимальное количество индексных дескрипторов в одном каталоге?
У меня есть каталог с более чем 2 миллионами файлов, и я не могу заставить команду ls работать с этим каталогом. Так что теперь мне интересно, не превысил ли я лимит на индексные дескрипторы в Linux. Есть ли предел перед числовым пределом 2 ^ 64?





Можете ли вы реально подсчитать количество файлов? Он падает очень близко к границе 2 ^ n? Может быть, у вас просто не хватает ОЗУ для хранения всех имен файлов?
Я знаю, что, по крайней мере, в Windows производительность файловой системы резко упадет по мере увеличения количества файлов в папке, но я думал, что Linux не страдает от этой проблемы, по крайней мере, если вы используете командную строку. Бог поможет вам, если вы попытаетесь заставить что-то вроде nautilus открыть папку с таким количеством файлов.
Еще мне интересно, откуда эти файлы. Умеете ли вы программно вычислять имена файлов? В этом случае вы могли бы написать небольшую программу для сортировки их по нескольким подпапкам. Часто перечисление имени конкретного файла дает вам доступ, когда попытка найти имя не удастся. Например, у меня есть папка в Windows с примерно 85 000 файлов, где это работает.
Если этот метод окажется успешным, вы можете попытаться найти способ сделать эту сортировку постоянной, даже если она просто запускает эту небольшую программу как задание cron. Это будет особенно хорошо работать, если вы сможете где-нибудь отсортировать файлы по дате.
Нет. Ограничения inode устанавливаются для каждой файловой системы и определяются во время создания файловой системы. Возможно, вы достигли другого предела, или, возможно, ls просто не работает так хорошо.
Попробуй это:
tune2fs -l /dev/DEVICE | grep -i inode
Он должен сообщать вам всевозможную информацию, относящуюся к индексным дескрипторам.
Если вы не получаете сообщение об ошибке, ls работает, но очень медленно. Вы можете попробовать просмотреть только первые десять файлов следующим образом:
ls -f | head -10
Если вам нужно какое-то время взглянуть на детали файла, вы можете сначала поместить их в файл. Вероятно, вы захотите отправить вывод в другой каталог, чем тот, который вы указываете в данный момент!
ls > ~/lots-of-files.txt
Если вы хотите что-то сделать с файлами, вы можете использовать xargs. Если вы решили написать какой-либо сценарий для выполнения этой работы, убедитесь, что ваш сценарий будет обрабатывать список файлов как поток, а не все сразу. Вот пример перемещения всех файлов.
ls | xargs -I thefilename mv thefilename ~/some/other/directory
Вы можете объединить это с головой, чтобы переместить меньшее количество файлов.
ls | head -10000 | xargs -I x mv x /first/ten/thousand/files/go/here
Вы, вероятно, можете объединить ls | head в сценарий оболочки, чтобы разделить файлы на группу каталогов с управляемым количеством файлов в каждом.
ls | head -10 не работает, чтобы получить немедленный результат, потому что ls выполняет сортировку - поэтому ему нужно прочитать все, прежде чем он сможет что-либо напечатать.
В этом случае попробуйте: ls -f | голова -10
df -i должен сообщить вам количество используемых и свободных индексных дескрипторов в файловой системе.
Попробуйте ls -U или ls -f.
ls по умолчанию сортирует файлы по алфавиту. Если у вас 2 миллиона файлов, такая сортировка может занять много времени. Если ls -U (или, возможно, ls -f), имена файлов будут напечатаны немедленно.
Максимальный размер каталога зависит от файловой системы, и поэтому точный предел варьируется. Однако иметь очень большие каталоги - плохая практика.
Вам следует подумать о том, чтобы уменьшить размер ваших каталогов, отсортировав файлы по подкаталогам. Одна из распространенных схем - использовать первые два символа для подкаталога первого уровня, как показано ниже:
${topdir}/aa/aardvark
${topdir}/ai/airplane
Это особенно хорошо работает при использовании для именования UUID, GUID или значений хэша содержимого.
Как заметил Роб Адамс, ls сортирует файлы перед их отображением. Обратите внимание, что если вы используете NFS, сервер NFS будет сортировать каталог перед его отправкой, и 2 миллиона записей вполне могут занять больше времени, чем тайм-аут NFS. Это делает каталог недоступным для списка через NFS, даже с флагом -f.
Это может быть верно и для других сетевых файловых систем.
Хотя принудительного ограничения на количество записей в каталоге нет, рекомендуется ограничить количество ожидаемых записей.
Для NetBackup двоичные файлы, которые анализируют каталоги в клиентах, выполняют некоторый тип перечисления этих таймаутов по огромному количеству файлов в каждой папке (около миллиона на папку, рабочий каталог SAP).
Мое решение было (как пишет Чарльз Даффи в этой теме) реорганизовать папки во вложенные папки с меньшим количеством архивов.
find . -name * -exec somcommands {} \;
{} - это абсолютный путь к файлу.
Преимущество / недостаток в том, что файлы обрабатываются один за другим.
find . -name * > ls.txt
напечатает все имена файлов в ls.txt
find . -name * -exec ls -l {} \; > ls.txt
будет печатать всю информационную форму ls для каждого файла в ls.txt
Вы должны включить подстановочный знак в одинарные кавычки, если вы не хотите, чтобы он расширялся оболочкой (это может быть довольно долго, если есть +2 миллиона файлов!)
Вы должны узнать о команде xargs. Это намного эффективнее, чем опция -exec команды find.
@Didier Trosset, новые версии стандарта POSIX поддерживают find ... -exec {} + (а не -exec {} ;), эффективность которого аналогична xargs.
Вы достигли внутреннего лимита в ls. Вот статья, которая довольно хорошо это объясняет: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls/
Вы имеете в виду максимальное количество <I> записей </I> в одном каталоге, верно? В конце концов, вы можете сделать 2 миллиона жестких ссылок на один и тот же файл в одном каталоге, и это вызовет ту же проблему.