Удалить овер дохрена файлов в одной директории

Есть такой хитрый трюк. Создаёшь рядом пустой каталог, а потом делаешь rsync --delete пустого каталога на каталог с кучей файлов. Единственный рабочий способ, который я пока смог найти.

Опередил, чёрт.

find /yourdir -delete

А мне вот кааца что финд тоже ласты склеит как и рм. Да и проверять уже не буду — запустил рсинк, фурычит, не жрет ресурсы, пока в процессе.

Склеит, да.

http://habrahabr.ru/post/157613/

Как удалить директорию в которой больше 1КК файлов?

Напиши сам, что ты как не мужик. Даю наводки:

man 2 open
man 2 getdents
man 2 unlinkat

man 2 getdents

syscall(SYS_getdents, fd, buf, BUF_SIZE);

Все таки POSIX это хорошо.

find | xargs -n 100 rm -f

ls -1f | xargs rm

еще никогда не подводил

Есть такой хитрый трюк

Как-будто меньше syscall'ов будет! Кончайте херней маятся.

Самый оптимальный вариант, см. постом выше

Кароч да. Рсинк проработал всю ночь. Я его тоже кильнул. Вобщем щас работает «ls -f . | xargs -n 100 rm». Сегодня за утро я трижды его останавливал и проверял оставалось еще (прогресс) 8646387 — 8501818 — 8036421 файлов. Скорее всего рсинк тоже что-то успел сделать за ночь. Вобщем до окончательного удаления еще несколько часов.

Anakros, post-factum, subwoofer, dvrts, MumiyTroll, kawaii_neko — походу у меня тут особо запущенный случай ))

FS какая?

ext3

Вот как удаляют файлы мужики: http://pastebin.com/cYZk73Xy

gcc -O2 -Wall -o cleardir cleardir.c
./cleardir dir1 dir2 dir3

Я запускал rm, так он выжрал 4.9 гб памяти и несколько часов тупил так ничего и не сделав. Я его кильнул.

а ты случаем не

rm -rf dir/* делал? Тогда память выжрал bash, а не rm.

Если rm -rf dir не поможет, попробуй через

find dir -name «*» -exec rm -f '{}'

у меня когда-то такая же проблема была. Примерно так и решал.

Делал rm -rf dir выжрало 4.9 гб.
Не делал find dir -name «*» -exec rm -f '{}' — но выше сказали что так же склеит ласты.
Всю ночь работал рсинк, не знаю что он там наработал, утром я его кильнул.
Сейчас работает ls -f . | xargs -n 100 rm и видно что процесс идет, осталось 6111061 файлов.

Совсем же недавно была такая же тема.

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

да это же ошибка уже 12310! ичсх, самое главное - никто не виноват. утилиты написаны с использованием стандартов, ФС ведёт себя не аварийно, просто мало памяти.

Неделю назад удалял финдом 6млн. мелких текстовых файлов, отработал минут за 20.

У тебя овер дохрена это сколько?

Щас осталось 4474433 файлов, а сколько их вчера вечером было я не смотрел.

но выше сказали что так же склеит ласты.

глупость тебе сказали

find /path/to/dir -type f -delete

спасает галактики. Рсинком тоже можно, теоретически, но это попахивает каким-то извратом.

Ну давай я финдом в следующий раз попробую, ладна? ))

Давай:) Вот и посмотрим, кто окажется прав:)

Даже сегодня на другой директории, правда там файлов не овер дохрена.

Начинаю думать, что проблема в ext3.

Скорее проблема в рейде из двух стареньких хардов.

Я запускал rm, так он выжрал 4.9 гб памяти и несколько часов тупил так ничего и не сделав. Я его кильнул.

ты что-то явно не так сделал. НЕ мог rm занять 5G памяти (даже с твоими миллионами файлами).

покажи командруню строку с помошью которой ты пытался это сделать :-)

perl -e 'chdir "BADnew" or die; opendir D, "."; while ($n = readdir D) { unlink $n }'

http://blogs.perl.org/users/randal_l_schwartz/2011/03/perl-to-the-rescue-case...

http://habrahabr.ru/post/157613/

Да и был же подобный топик.

php-мартышки накосячили, кстати? =)

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

Да и был же подобный топик.

такие топики периодически встречаются :-) ..

а ещё можно перевести этот топик в срач между Extfs-vs-Btrfs [но боюсь как бы сюда не прискакали бы фанатики zfs] ..

ведь проблема больших каталогов — это бич именно файловой системы Extfs :-)

это бич именно файловой системы Extfs :-)

Это бич крук кривых разработчиков, в большей массе php-сты

Ты не внучек Ванги, случаем?

Это бич крук кривых разработчиков, в большей массе php-сты

только если они забывают удалять свои говносессионные файлы :-)

но поумолчанию — должно всё удаляться.

см — http://php.net/manual/en/session.configuration.php#ini.session.gc-divisor

Или картинок в одну директорию по-на-серут-аплоадят.

Или картинок в одну директорию по-на-серут-аплоадят.

да.. а вот я ещё что думаю.. а почему бы не хранить эти картинки внутри базы данных?

аватарки пользователей, или иллюстрации в блог-страницы, или фотки товаров в интернет-магазинах..

неужто прям так важно чтобы картинки были бы статикой?

не говоря уже о том что web-браузер умеет кеширование по etag. и таким образом каждому человеку (каждому web-клиенту) картинка будет извлекаться из базы данных не более одного раза [если конечно web-разработчик заиспользует этот etag].

Етег вроде и нжинкс может. А статика потому что может в перспективе будет какое-то облако, ато еще и до реплик бд дойдет, ну просто мух от котлет.

Последнее что было ~20kk мелких сессионных файлов, вотъ

Етег вроде и нжинкс может.

ты должен *сам* (как web-разработчик) определять правила при которых etag будет определять политику кеша web-браузера.

иначе неужели ты наивно думаешь будто якобы Nginx «волшебным образом» сам откуда-то знает наколько является актуалены текущий кэш в web-браузере? :-) ды Nginx вообще не-в-курсах!

вот смотри:

web-браузер делает запрос:

"дай мне картинку аватарку ``qwerty-wertyu.jpg``! etag моего кэша вот такой: ``ertyuio``"

и сервер должен ответить:

"всё нормально! твой кэш актуален! ни чего передавать тебе не буду.."

или ответить:

"ох! ну ты что! вот тебе свежи данные..... <далее-передаются-данные>"

откуда Nginx знает как поступить, если картинка находится внутри базы данных, а не внутри файловой системы? :-)

Если картинка в фс, тогда может знать.

А статика потому что может в перспективе будет какое-то облако, ато еще и до реплик бд дойдет, ну просто мух от котлет.

если ты планируешь облако — то вообще тебе НЕЛЬЗЯ использовать ни какой статити для динамических данных.

[[аплоад картинок {аватарки, иллюстрации блога, фотографии товаров} — это динамические данные!]]

потому что ты не сможешь корректно организовать консистентность динамических данных в случае облачных технологий... КРОМЕ как использованием базы данных (очевидно, распределённой).

так что да — засовывай «аплоад» в базу данных :-)

https://pp.vk.me/c543106/v543106884/7a24/O-kYZ_jzVwA.jpg

Последнее что было ~20kk мелких сессионных файлов, вотъ

интересно было бы глянуть на этот PHP-код :) ..

я имею ввиду, по какой причине PHP-программист (который создал тебе эту проблему) отключил сборку мусорных сессионных файлов? :-)

ведь он сделал это с каким-то умыслом? o_0

Просто переопределил место хранения сессионных файлов и все. А гц по крону только в тмп ходит, т.е. только в стандартное место.

ls -1f | xargs rm

еще никогда не подводил

> [...]

Как-будто меньше syscall'ов будет! Кончайте херней маятся.

Самый оптимальный вариант, см. постом выше

твой вариант — МЕНЕЕ оптимален чем ``rm -Rf /путь/к/каталогу/без/звёздочек`` ..

и да, на чтение-и-передачу PIPE-данных — на это тоже тратятся syscall`ы :-)

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

по мне проще под такие директории выделять раздел и тупо формат делать.