Как эффективно удалить МИЛЛИАРДЫ файлов в Linux?

Использование только GNU и механизм регулярных выражений:

Командная строка

pip... |& grep -oP '.*\b\K\d+\.\d+\.\d+\b'

Выход

19.9.0

Пояснения к регулярному выражению

Проверить объяснения regex101

8
27.11.2021, 03:48
3 ответа

Вы можете монтировать раздел с большим интервалом фиксации (это относительно безопасно, но может быть бесполезно )или сnobarrier(должно помочь ), что чрезвычайно опасно с точки зрения потери питания или сбоя ядра.

Магия асинхронного ввода-вывода может помочь, но я не могу предложить никаких инструментов.

2
28.11.2021, 00:12

Без доступа к системе и без экспериментов было бы сложно проверить, что работает, что помогает, а что бесполезно; но мой путь был бы таким:

Вкратце :Не удаляйте ненужные файлы, а mvих в каталоги (, что должно быть быстрой операцией ), а затем усекайте файлы здесь до размера 0 (, чтобы получить место назад ); позже вы можете rmкаталоги (полностью удалить файлы и вернуть индексные дескрипторы ); каждый из этих трех этапов может выполняться параллельно или последовательно в зависимости от загрузки системы.

Детали:
Создайте каталог X.
В одном сценарии оболочки S1, mvоколо N=500 нежелательных файлов в X/latest и переименуйте их в X/X1, mvследующие N нежелательных файлов в X/latest и переименуйте их в X/X2, mvnext N нежелательных файлов в X/latest и переименовать их в X/X3....
В другом сценарии оболочки S2 перейдите в каждый каталог X/X1, X/X2,X/X3 с N файлами, обрезать файлы до размера 0 и переименовать этот каталог в X/0X1, X/0X2, X/0X3....
В последнем сценарии оболочки S3 rmкаталоги X/0X1, X/0X2 X/0X3....

Здесь имя каталога гарантирует, что каждый сценарий оболочки независим и не будет мешать другим. :S1 работает с X/latest ; S2 работает с X/X1, X/X2, X/X3... ; S3 работает с X/0X1, X/0X2, X/0X3... :конфликтов нет!

Проверьте, можно ли выполнять каждый из этих трех этапов параллельно или последовательно в зависимости от загрузки системы. Варьируйте N и используйте niceи ioniceс sleepдля управления нагрузкой системы.

Альтернативное предложение:
Используйте новое место для хранения новых версий и позвольте пользователям смотреть здесь по умолчанию. Вы даже можете заполнить это новое местоположение(cpилиmv)ревизиями, созданными за последний 1 месяц.
В случае, если одному пользователю нужны «все версии», только тогда получите доступ к старому местоположению.
Это гарантирует, что старое местоположение не разрастется. Затем вы можете легко rmудалить ненужные очень старые ревизии без нагрузки на систему.

4
28.11.2021, 06:18

Как указал @prem, mv, как правило, много быстрее, чем rm-, поэтому трюк может быть от mvдо /dev/null, это может иметь явное преимущество в скорости.

К сожалению, , , как указано в комментариях , /dev/nullявляется специальным файловым устройством, однако, если вы хотите и можете исправить ядро,можетобнаружить, что nullfs используется с rsyncв варианте использования Простое выборочное удаление файлов кэша .

-3
03.12.2021, 18:34

Теги

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