LINUX.ORG.RU

Быстрое удаление каталога с огромным количеством вложенных файлов и подкаталогов

 ,


0

2

Столкнулся с проблемой следующего рода:

Имеется каталог, с большим количеством подкаталогов и уровнем вложенности который определить не представляется возможным.
Общий размер каталога около 20Гб, количество файлов более 10 млн. Точное количество файлов определить не хватило терпения (более 3 часов ждал, не долждался), а размер определил методом: вычесть из общего размера занятого на диске размер прочих каталогов, чей размер определить удалось.

Задача: удалить этот каталог со всем его содержимым за минимальный промежуток времени и с минимальным износом ЖД (все это дело на ноутбуке).

пробовал сделать «rm -rfd folder_name», ждал 3 часа, освободило не более 3 Гб и с каждым часом скорость очистки замедлялась...

Может кто другие, более производительные методы подскажет?



Последнее исправление: Lorence (всего исправлений: 1)

перенести все остальное на другой винт, а этот форматнуть и впредь так не делать

Deleted
()
Ответ на: комментарий от anonymous

подробнее пожалуйста, если можно?

Lorence
() автор топика

а) +1 за идею забэкапить все кроме этого каталога, снести все нафиг, восстановить все кроме каталога

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

afiskon
()
Последнее исправление: afiskon (всего исправлений: 1)

ждал 3 часа, освободило не более 3 Гб

Ну подожди еще сутки. Можно подумать, ты эти три часа педали крутил чтоб оно удалялось.

Deleted
()
Ответ на: комментарий от ananas

Дык, я только что сидел, пытался. Оказывается, поломали, сволочи!

Надо восстановить справедливость и пропатчить glibc, чтобы unlink перестал проверять, является ли хрень по указанному адресу директорией, если его запускают от рута.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от ananas

Да пофиг. Главное — поломали же такую классную вещь!!!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от KRoN73

Вот здесь вот http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux perl-скрипт бысрее, чем rsync.

А про износ диска ТС-у никто не ответил. Может ему нужно перемонтировать ФС или что написать в /proc, чтобы было усиленное кеширование записи?

mky ★★★★★
()
Ответ на: комментарий от Deleted

Такое вытворял не я, а человек работавший ранее на этом рабочем месте. Сносить все это хозяйство опять же не предоставляется возможным, слишком много инфы + / & /home в одном разделе, так что...

Lorence
() автор топика
Ответ на: комментарий от mky

Я не думаю, что разовое удаление такого каталога заметно скажется на износе диска.

А вот если задача становится многократно, я бы посоветовал посмотреть в сторону reisrefs. Мне часто приходится работать с кешами, когда несколько десятков или сотен тысяч файлов на несколько гигабайт или десятков гигабайт лежат в на 2-3 уровнях вложенности в подкаталогах. ext4 на такой структуре через какое-то время использования становится адом. Я несколько лет мучился, пока не рискнул reisrefs проверить, памятуя, что лет 10-15 назад серьёзных проблем с такими структурами (с небольшими поправками на развитие железа) у меня не было. А вправду, одна только синхронизация по rsync на таких объёмах, занимая на ext4 десяток минут, на reiserfs отрабатывает за минуту. Даже (на машинах без lvm, когда легко не переразбить диск) быстрее оказывается в плане скорости поставить reisrefs в файл-образ на ext4.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

debugfs open -w /dev/sdЁ rm каталог close q

anonymous
()

в общем, решил воспользоваться старым добрым MC.
В итоге наглядно видно как удаляется весь хлам из каталога + не обязательно ждать пока просканирует все содержимое и составит список файлов.

Скорость удаления держится в районе 40 000 файлов в минуту и не падает не смотря на продолжение активной работы на ноутбуке (ЖД не гудит и не греется).

Всем спасибо, думаю, вопрос решен.

PS perl скрипт из поста выше не заработал, т.к. он удаляет только файлы, а вложенные подкаталоги смотреть не умеет.
PPS rsync не пробовал, не рискнул

Lorence
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.