Быстрое удаление гигантского каталога в Linux на диске Ext3 / 4

414
Karl Damgaard Asmussen

Я работал над некоторой дедупликацией данных, которая заставила меня использовать файловую систему в качестве хеш-таблицы. Это привело к некоторым каталогам, которые потребовались буквенные часов, чтобы удалить, используя практически любой разумный метод (то есть rm -rf, ls -f1 | xargs rm, find -deleteи т.д.)

В файловых системах Ext2 / 3/4 каталог - это файл, содержащий хеш-таблицу от имен файлов до номеров инодов (в моем случае, около 60 МБ!). Как я понимаю, работа rm -rfс друзьями выполняется медленно, потому что она следует этой методологии:

Выполните итерацию по хеш-таблице в файле каталога. Для каждой пары имя файла-inode встречается атомарно:

  1. Уменьшить счетчик имен в индоде.
  2. Удалить запись из хеш-таблицы.

(Удаление файлов / инодов происходит, когда их количество имен достигает 0, и нет программ с открытыми файловыми дескрипторами, которые указывают на эти иноды.)

Уменьшение количества имен в inode происходит быстро.

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

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

То, что я спрашиваю, имеет два аспекта:

  • Верны ли мои рассуждения, поскольку это манипулирование хэш-таблицами, которое замедляет процесс?

  • Если это так, есть ли инструмент, который делает следующее (и, таким образом, это, вероятно, намного быстрее?)

    1. Уменьшите количество имен для каждого индекса, указанного в файле каталога.
    2. Удалить все содержимое всего каталога за один раз.
3

2 ответа на вопрос

2
miravalls

Удаление всего дерева - дорогостоящая операция, но могут быть способы ускорить его.

Вы пробовали решение, указанное в этом ответе и в этом ответе ? rsyncкажется самым быстрым, поскольку она оптимизирует операции удаления вместо того, чтобы просто идти по списку файлов, как rm, find... делаем.

Кроме того, вы пробовали эту альтернативу?

РЕДАКТИРОВАТЬ:

Обратите внимание: я не тестировал эти команды.

Команды, на которые я ссылаюсь в случае разрыва ссылок в будущем:

rsync Команда первых двух ссылок:

mkdir blank rsync -a --delete blank/ test/

Третья ссылка: «Переместить их в скрытый каталог, а затем удалить его в фоновом режиме»:

mkdir ../.tmp_to_remove mv -- * ../.tmp_to_remove nohup rm -rf ../.tmp_to_remove &

Как объясняется в этом ответе, этот подход предполагает, что (даже если удаление очень дорогое), поскольку удаление происходит в фоновом режиме в другом дереве, пользователь может не заботиться о фактической стоимости. На мой взгляд, это так до тех пор, пока вы не попытаетесь закрыть сеанс bash / ssh до того, как произойдет операция удаления. Чтобы это исправить, я добавил nohupв rmкоманду.

@KamilMaciorowski спасибо за ваш отзыв. Я обновил свой ответ после вашего предложения. miravalls 6 лет назад 0
2
Theodore Ts'o

Каталог ext3 / 4 сам по себе не является хеш-таблицей. Это на самом деле хэш-дерево. То есть имя файла хэшируется, а хэш используется как индекс для вставки в дерево b +. Самый быстрый способ удалить все файлы - это отсортировать файлы по номеру инода, поскольку это сведет к минимуму поиск дисков, необходимый для извлечения инодов из таблицы инодов в память, и обновления таблицы инодов по мере освобождения файлов., Это также приведет к удалению файлов в том порядке, в котором они были созданы, что оптимизирует процесс обновления различных битовых карт выделения блоков и узлов. Еще одна вещь, которую вы можете сделать, это поможет увеличить размер журнала (удалите журнал с помощью tune2fs, а затем заново создайте его с большим размером журнала).

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

Теодор Цо отвечает на случайный вопрос о ext3 / 4. Ницца. :) Я также видел физика лауреата Нобелевской премии, отвечающего на Physics SE, и я люблю, когда такие вещи случаются! Может быть, Папа по христианству SE мог бы победить это, но я не видел, чтобы это произошло (пока). Kamil Maciorowski 6 лет назад 0
Спасибо за разъяснение этого! И да, база данных была бы намного предпочтительнее; но настроить его на работу займет больше времени, чем взломать его. Я работаю в науке о данных, и мне стыдно. Karl Damgaard Asmussen 6 лет назад 0

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