Re: OpenVZ, VServer и полудесяток
On 25-Dec-2007, Alexey Pechnikov wrote:
> Тогда по идее rm -rf /test/test_10000/ должно работать быстро, поскольку
> список файлов не передается.... Здесь-то что мешает?
Надо пройти по всем файлам рекурсивно, сделать unlink, если какой-то процесс
держит файл открытым, удаление будет откладываться, как и удаление каталогов к которых он находится.
что наверняка и проиходит.
обходных путей несколько, в разной степени корретных, но я сомневаюсь, что тикл их использует. Разве что если эти
файлы от как сам и держит:)
>
> > Решение:
> > find /test/test_10000/ -type f |xargs rm
> > Немного более кошерно:
> > find /test/test_10000/ -type f -print0 |xargs -0 rm -f
> > Вообще это может и сам find:
> > find /test/test_10000/ -type f -delete
> > Но xargs более универсальная вещь.
> > Глубина рекурсии для поиска по умолчанию не ограничена, чтобы не трогать
> > подкаталоги:
> > find /test/test_10000/ -type f -maxdepth=1 |xargs rm
> >
> >
> > Насчет вашего варианта на тикле - он хуже(съест дофига ram, если файлов
> > много), и явно медленнее решения с find.
>
> Интересно, откуда это следует. Буду пробовать. Сдается мне, что если запускаю
> один интерпретатор тикля, то это будет не медленнее варианта с find, который
> тоже еще надо проверить по скорости.
у find всё ok со скоростью, особенно если перенаправлять стандартный
вывод в другую программу.
xargs будет формировать из ст.входа куски максимальной длины и запускать
с поочередно rm со след.куском
__поиск и удаление работают паралельно__, расход оперативной памяти
будет ограничен, а если rm не будет успевать удалять файлы то find`у
придется его ждать.
а последовательный вариант - это сформировать весь массив, ждать когда
отработает find, интерпретировать его вывод, потом запускать rm для
каждого файла.
> Идея понятна. Только на тикле это рабочее решение, а на баше - лишь пример.
на баше это тоже рабочее решение.
просто крайней неоптимальное.
> Хотя если в используемом шёлле подобные команды встроены, то и проблемы быть
> не должно.
а) проблема с unlink`ами никуда не делась
б) лучше использовать xargs. это один из случаея, когда xargs очень рулит.
в) оптимальные задачи для шелла вообще это перенаправление выхода и
входа. фактически накладных расходов минимум - несколько системных
вызовов и дальше всё делает ядро.
Reply to: