Использование только GNU grep и pcre механизм регулярных выражений:
pip... |& grep -oP '.*\b\K\d+\.\d+\.\d+\b'
19.9.0
Проверить объяснения regex101
Вы можете монтировать раздел с большим интервалом фиксации (это относительно безопасно, но может быть бесполезно )или сnobarrier
(должно помочь ), что чрезвычайно опасно с точки зрения потери питания или сбоя ядра.
Магия асинхронного ввода-вывода может помочь, но я не могу предложить никаких инструментов.
Без доступа к системе и без экспериментов было бы сложно проверить, что работает, что помогает, а что бесполезно; но мой путь был бы таким:
Вкратце :Не удаляйте ненужные файлы, а mv
их в каталоги (, что должно быть быстрой операцией ), а затем усекайте файлы здесь до размера 0 (, чтобы получить место назад ); позже вы можете rm
каталоги (полностью удалить файлы и вернуть индексные дескрипторы ); каждый из этих трех этапов может выполняться параллельно или последовательно в зависимости от загрузки системы.
Детали:
Создайте каталог X.
В одном сценарии оболочки S1, mv
около N=500 нежелательных файлов в X/latest и переименуйте их в X/X1, mv
следующие N нежелательных файлов в X/latest и переименуйте их в X/X2, mv
next 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
удалить ненужные очень старые ревизии без нагрузки на систему.
Как указал @prem, mv
, как правило, много быстрее, чем rm
-, поэтому трюк может быть от mv
до /dev/null
, это может иметь явное преимущество в скорости.
К сожалению, , , как указано в комментариях , /dev/null
является специальным файловым устройством, однако, если вы хотите и можете исправить ядро,можетобнаружить, что nullfs используется с rsync
в варианте использования Простое выборочное удаление файлов кэша .