Как лучше всего обрабатывать папки с миллионами файлов в RHEL -7?

Попробуйте с флагом -f

sudo chattr  -f   +i   /etc/resolv.conf
0
24.01.2021, 03:17
5 ответов

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

$ find /bigdatadir -print | cpio -pdm /newbigdatadir
-1
18.03.2021, 22:35

Я считаю, что Midnight Commander — это инструмент, который может помочь вам работать с большим комфортом. Он перечисляет файлы, используя поток, как и меньше, поэтому теоретически он, насколько возможно, будет иметь хорошую производительность.

Он также предоставляет функцию «Фильтр», поэтому его можно использовать перед копированием любого файла. Это облегчит визуализацию ваших файлов, поэтому вам не нужно будет снова и снова перечислять файлы. Кроме того, с помощью функции просмотра/редактирования вы сможете открыть файл и отредактировать файл без необходимости повторного отображения папки.

0
18.03.2021, 22:35

Просто выкинул это туда...

что не так со сценарием оболочки, чтобы сделать что-то вроде

tar -cf newdir/a/a.tar /hugedir/a*
tar -cf newdir/b/b.tar hugedir/b*

или нечто подобное,

cd hugedir/
mkdir a
mkdir b
ln -s a*./a/
ln -s b*./b/

Еще одна идея может заключаться в использовании языка, python или bash, который может выполнять логический список/цикл или логику сравнения (независимо от того, что язык поддерживает и делает, поскольку )это будет воздействовать на каждый файл. в порядке диска, а не в отсортированном порядке. Да, скриптовый метод будет обращаться к каждому файлу, и это займет вечность, но он сделает это только один раз.

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

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

0
18.03.2021, 22:35

Прочтите man find xargs cpи выполните что-то вроде

find ~/bigdir -type f -name '*.js' -print0 | \
    xargs -0 -r echo cp --target-directory=~/destination

Удалите " echo", когда будете довольны результатом.

3
18.03.2021, 22:35

Вам нужно думать об этой проблеме с точки зрения конечной цели, а не текущей ситуации.

То есть :какого конечного результата вы пытаетесь достичь? Я бы предположил, что у вас могут быть такие цели, как:

.. Реструктурируйте все файлы в новый каталог с подходящей многоуровневой древовидной структурой -.

.. Удалите (в конце концов )файлы из исходного каталога, чтобы вы могли rmdirего удалить, когда он пуст, и восстановить пространство, занимаемое самим каталогом.

Каталог не может содержать повторяющиеся имена, поэтому у вас есть 8 миллионов уникальных имен. Это предполагает структуру имени файла, основанную на дате, времени, серийном номере, коде проекта и т. д. Было бы полезно понять, что это за структура, потому что она предполагает разделение конечного результата (, например. как ./2018/20180923/syslogs/..., если они являются датой -проштампованными бревнами ).

Решения, включающие cp, tar, ln, бесполезны, поскольку они оставляют исходный каталог без изменений. В частности, cpбудет дублировать весь набор данных, занимая огромное пространство и время. Вам действительно нужно mvпереместить файлы на новое место.

Вы даже не можете rmdir hugedirв конце, потому что он не удалит каталог с файлами. rm -rf hugedirне помогает :он просто рекурсивно запускает rm -r *в дереве каталогов в любом случае,так что он все еще бегает как собака.

Это будет хорошо работать, только если вы (a )обрабатываете файлы в пакетном режиме; (b )выбор пакетов файлов в исходном порядке каталогов; (c )удалять файлы по мере необходимости. Удаление файлов в необработанном порядке не приводит к исчезновению этих блоков каталогов (может помочь в ext4, но не полагайтесь на него ), но они гораздо быстрее сканируются снова, если они пусты (и вполне возможно кэшировано ).

Побывав здесь, я нашел следующее решение::

(1 )Установите новую структуру и создайте все необходимые каталоги.

(2)ls -U hugedir | head -n 10000для эффективного получения списка файлов управляемого размера, работающего с заголовком каталога.

(3 )Передайте этот список сценарию, который перемещает каждый файл в новое место, используя ранее установленные вами правила. Если вы можете сгруппировать эти команды mvпо целевому каталогу (mv -t aa bb cc...), это немного оптимизируется. mvтакже максимально эффективно удалит их из hugedir.

(4 )Промыть и повторять до тех пор, пока hugedirне будет содержать файлов(ls -Uне вернет имен ). В этом случае повторите примерно 800 раз (в цикле скрипта, очевидно, ).

(5 )Если эти данные ценны, стоит создать урезанный -тестовый каталог, чтобы подтвердить пригодность и время. В частности, я бы сделал полный ls -U > myTestList.txtи последовательно запускал его через свои правила имен, считая по цели, и имел бы перехват -для всех неожиданных форматов имен.

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

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

Я создал два миллиона пустых файлов в одном каталоге (за 13 минут ). Мои тайминги показывают, что lsпочти в 10 раз медленнее, чем ls -U, а ls -lпочти в 20 раз медленнее. Я ожидаю, что восемь миллионов будут пропорционально хуже. ls -U | head -n 10000возвращает первую группу имен за 0,034 с.

$ time ls -U HugeDir | wc -l  #.. takes real    0m3.962s
$ time ls HugeDir    | wc -l  #.. takes real    0m38.135s
$ time ls -l HugeDir | wc -l  #.. takes real    1m14.688s

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

$ time find HugeDir -type f -print | wc -l  #.. takes real  0m8.566s
0
18.03.2021, 22:35

Теги

Похожие вопросы