Найти файлы в огромной директории - очень медленно

У меня есть каталог с файлами. Архив очень большой и имеет 1,5 миллиона PDF-файлов внутри.
каталог хранится на сервере IBM i с ОС V7R1, и машина новая и очень быстрая.
Файлы названы так:

invoice_[custno]_[year']_[invoice_number].pdf  
invoice_081500_2013_7534435564.pdf    

Нет, я пытаюсь найти файлы с помощью команды поиска с помощью командной консоли.

find  . -name 'invoice_2013_*.pdf'  -type f | ls -l > log.dat

Команда заняла много времени, поэтому я прервал операцию безрезультатно.

Если я попробую это с меньшими каталогами, все работает отлично.

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

5 ответов

Решение

Этот вызов никогда не будет работать, потому что ls не читает имена файлов из stdin,

Возможные решения:

Использовать find Опция встроенного списка утилиты:

find . -name 'invoice_2013_*.pdf' -type f -ls > log.dat

Использовать find утилиты -exec возможность выполнить ls -l для каждого соответствующего файла:

find . -name 'invoice_2013_*.pdf' -type f -exec ls {} \; > log.dat

Передайте имена файлов в xargs утилита и дайте ей выполнить ls -l с именами файлов в качестве параметров:

find . -name 'invoice_2013_*.pdf' -type f | xargs ls -l > log.dat

Поиск по шаблону из 1,5 миллионов файлов в одном каталоге будет неэффективным в любой файловой системе.

Для просмотра только списка новых записей в каталоге, вы можете рассмотреть возможность ведения журнала в каталоге. Вы бы указали INHERIT(*NO) чтобы предотвратить ведение журнала всех файлов в каталоге, а также. Затем вы можете просто извлечь последние записи журнала с помощью DSPJRN, чтобы узнать, какие объекты были добавлены.

Я не думаю, что я поместил бы больше чем 15k файлов в один каталог. У некоторых утилит QShell возникают проблемы с файлами размером около 16 КБ. Но я не уверен, что буду хранить их в каталоге в любом случае, за исключением, может быть, для более чем 16 МБ, если это значительная часть общего объема. Возможно, я бы хотел сначала сохранить их в CLOB /BLOB в базе данных.

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

Храня в базе данных, вы переходите на один принадлежащий объект.

Или, возможно, несколько похожих объектов... Может быть процесс очистки / архивирования, который перемещает строки во вторичную или третичную таблицу. Трудно догадаться, как это может быть необходимо структурировать, если вообще.

Экономия может также принести пользу, особенно SAVSECDTA и SAV. Безопасность данных значительно снижена. А сохранение таблицы 4 ГБ происходит быстрее, чем сохранение тысячи объектов 4 МБ (или любой другой разбивки).

Помимо определения того, как исходная установка и реализация будут проходить в вашей среде, большая сложная часть может включать волатильность. Если это стабильные объекты с относительно небольшим количеством изменений и небольшим удалением, все должно быть в порядке. Но если BLOB-объекты часто модифицируются, это может вызвать проблемы, когда таблица занимает значительную долю емкости DASD. Он становится особенно грубым, когда он превышает размер свободного пространства DASD, и требуется повторная организация. С низкой волатильностью это гораздо меньше проблем.

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

INHERIT(*NO)

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

Другие вопросы по тегам