Эффективно удаляйте 10M + файлов из ZFS

Я написал программу с ошибками, которая случайно создала около 30 миллионов файлов в каталоге / tmp. (Ошибка была введена несколько недель назад и создавала пару подкаталогов в секунду.) Я мог переименовать / tmp в / tmp2, и теперь мне нужно удалить файлы. Система FreeBSD 10, корневая файловая система zfs.

Тем временем один из дисков в зеркале вышел из строя, и я заменил его. Диск имеет два 120 ГБ SSD-диска.

Вот вопрос: замена жесткого диска и восстановление всего массива заняли меньше часа. Удаление файлов / tmp2 - это другая история. Я написал другую программу для удаления файлов, и она может удалять только 30-70 подкаталогов в секунду. Удаление всех файлов займет 2-4 дня.

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня? Почему у меня такая плохая производительность? 70 удалений в секунду - очень плохая производительность.

Я могу удалить inode для / tmp2 вручную, но это не освободит место, верно?

Может ли это быть проблемой с zfs, жесткими дисками или чем?

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

Возможно, вам лучше удалить /tmpкаталог, а не данные, содержащиеся в нем.

Если /tmpэто файловая система ZFS, удалите ее и создайте заново.

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня?

Рассмотрим офисное здание.

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

Разрушить все здание с гексогеном это гораздо быстрее, но следующий клиент вполне вероятно, жалуется , как сквозняк места есть.

Здесь происходит много вещей.

Во-первых, все современные дисковые технологии оптимизированы для массовых переносов. Если вам нужно переместить 100 МБ данных, они сделают это намного быстрее, если они будут в одном непрерывном блоке, а не разбросаны повсюду. SSD здесь очень помогают, но даже они предпочитают данные в смежных блоках.

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

В-третьих, удаление файла очень медленно . ZFS особенно плох, но практически все файловые системы медленно удаляются. Они должны изменить большое количество различных фрагментов данных на диске и правильно рассчитать их время (т. Е. Ждать), чтобы файловая система не была повреждена при сбое питания.

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня?

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

70 удалений в секунду - очень плохая производительность

Это зависит. Я бы не удивился этому. Вы не упомянули, какой тип SSD вы используете. Современные твердотельные накопители Intel и Samsung довольно хорошо справляются с такой операцией (чтение-изменение-запись) и будут работать лучше. Более дешевые / старые SSD (например, Corsair) будут работать медленно. Количество операций ввода-вывода в секунду (IOPS) является определяющим фактором здесь.

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

Приложение: почему удаление происходит медленно?

• Удаление файла требует нескольких шагов. Метаданные файла должны быть помечены как «удаленные», и в конечном итоге они должны быть восстановлены, чтобы пространство можно было использовать повторно. ZFS - это «файловая система со структурой журналов», которая работает лучше всего, если вы когда-либо только создаете вещи, но никогда не удаляете их. Структура журнала означает, что если вы что-то удаляете, в журнале есть пробел, поэтому другие данные должны быть перегруппированы (дефрагментированы), чтобы заполнить этот пробел. Это невидимо для пользователя, но обычно медленно.
• Изменения должны быть сделаны таким образом, чтобы в случае сбоя питания на полпути файловая система оставалась согласованной. Часто это означает ожидание, пока диск не подтвердит, что данные действительно находятся на носителе; для SSD это может занять много времени (сотни миллисекунд). Чистый эффект этого заключается в том, что ведется гораздо больше бухгалтерии (т.е. операций ввода-вывода на диске).
• Все изменения небольшие. Вместо того, чтобы читать, записывать и стирать целые флэш-блоки (или цилиндры для магнитного диска), вам нужно немного изменить один из них. Для этого оборудование должно прочитать весь блок или цилиндр, изменить его в памяти, а затем снова записать на носитель. Это занимает много времени.

Как это возможно, что восстановление всего массива занимает час, а удаление с диска занимает 4 дня?

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

Почему у меня такая плохая производительность? 70 удалений в секунду - очень плохая производительность.

Это должно сделать много бухгалтерии ...

Я могу удалить inode для / tmp2 вручную, но это не освободит место, верно?

Я не знаю, для ZFS, но если бы он мог автоматически восстановиться после этого, он, вероятно, в конце концов, будет делать те же операции, которые вы уже делаете, в фоновом режиме.

Может ли это быть проблемой с zfs, жесткими дисками или чем?

Что- zfs scrubнибудь говорит?

Удаление большого количества файлов никогда не бывает быстрой операцией.

Чтобы удалить файл в любой файловой системе, необходимо прочитать индекс файла, удалить (или пометить как удаленный) запись файла в индексе, удалить любые другие метаданные, связанные с файлом, и отметить пространство, выделенное для файла, как неиспользованными. Это должно быть сделано индивидуально для каждого удаляемого файла, что означает, что удаление большого количества файлов требует большого количества небольших операций ввода-вывода. Делать это таким образом, который обеспечивает целостность данных в случае сбоя питания, добавляет еще больше накладных расходов.

Даже без учета особенностей ZFS удаление 30 миллионов файлов обычно означает более ста миллионов отдельных операций ввода-вывода. Это будет занимать много времени , даже с быстрым SSD. Как уже упоминалось, дизайн ZFS еще больше усугубляет эту проблему.

Ян Хоусон дает хороший ответ о том, почему это медленно.

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

Так что попробуйте:

find /tmp -print0 | parallel -j100 -0 -n100 rm

и посмотрите, работает ли он лучше, чем ваши 70 удалений в секунду.

Очень просто, если вы измените свое мышление.

1. Получить второй диск (у вас, кажется, уже есть)

2. Скопируйте все с диска A на диск B с помощью rsync, за исключением каталога / tmp. Rsync будет медленнее, чем блочная копия.

3. Перезагрузитесь, используя диск B в качестве нового загрузочного тома

4. Переформатировать диск А.

Это также дефрагментирует ваш диск и даст вам новый каталог (хорошо, дефрагментация не так важна для SSD, но линеаризация ваших файлов никогда не повредит)

У вас есть 30 миллионов записей в несортированном списке. Вы сканируете список на предмет записи, которую хотите удалить, и удаляете ее. Теперь в вашем несортированном списке есть только 29 999 999 записей. Если они все находятся в / tmp, почему бы просто не перезагрузиться?

Отредактировано, чтобы отразить информацию в комментариях: Формулировка проблемы: удаление большинства, но не всех , неправильно созданных 30M + файлов в / tmp занимает много времени.
Проблема 1) Лучший способ удалить большое количество нежелательных файлов из / tmp.
Проблема 2) Понимание, почему это так медленно, чтобы удалить файлы.

Решение 1) - / tmp сбрасывается в пустую при загрузке большинством * nix-дистрибутивов. FreeBSD, однако, не является одним из них.
Шаг 1 - скопируйте интересные файлы в другое место.
Шаг 2 - как root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Шаг 3 - перезагрузка.
Шаг 4 - измените clear_tmp_enable обратно на «Нет».
Нежелательные файлы теперь исчезли, так как ZFS во FreeBSD имеет функцию, заключающуюся в том, что «Уничтожение набора данных происходит гораздо быстрее, чем удаление всех файлов, которые находятся в наборе данных, так как не включает сканирование всех файлов и обновление всех соответствующих метаданных. " поэтому все, что нужно сделать во время загрузки, - сбросить метаданные для набора данных / tmp. Это очень быстро.

Решение 2) Почему это так медленно? ZFS - замечательная файловая система, которая включает в себя такие функции, как постоянный доступ к каталогам. Это хорошо работает, если вы знаете, что делаете, но факты свидетельствуют о том, что ОП не является экспертом ZFS. ОП не указал, как они пытались удалить файлы, но я бы сказал, что они использовали вариант «find regex -exec rm {} \;». Это хорошо работает с небольшими числами, но не масштабируется, потому что выполняются три последовательные операции: 1) получить список доступных файлов (возвращает 30 миллионов файлов в порядке хеширования), 2) использовать regex, чтобы выбрать следующий файл, который нужно удалить, 3 ) скажите ОС найти и удалить этот файл из списка 30 миллионов. Даже если ZFS возвращает список из памяти и если 'find' кэширует его, регулярное выражение все равно должно идентифицировать следующий файл, который будет обработан из списка, а затем сказать ОС обновить свои метаданные, чтобы отразить это изменение, а затем обновить список, чтобы он не обрабатывался снова.