Хех

1 ноября 2013, 21:36

Экспериментирую сейчас со сжатием в zfs. Насоздавал пачку файлов, где-то в районе 100 тысяч штук. И косанул в команде создания, они создались не в том каталоге, в котором планировалось. В итоге нужно перенести 100 тысяч файлов в другой каталог. Команда mv ./xaaa* /storage/mail/ мне отвечает:

/bin/mv: Argument list too long.

Полез копаться, и выяснилось, что оказывается, оболочка раскрывает wildcard *, просто заменяя её на имена подходящих под шаблон файлов и подставляя в реальную команду. В итоге получалось, что командная строка для mv была нефиговой такой длины. В качестве решения предлагали удалять файло через find :-) Я сделал так: find ./ -type f -exec mv {} /storage/mail \;

Хинт: разделить один файл (например, сгенерированный с помощью dd из /dev/urandom) на кучу мелких можно так:

split -b 1024 -a 10 /storage/mail/test.dat

Где «-b 1024» — размер одного файла, а «-a 10» — количество символов в имени минус 1 символ. Т. е. «-а 10» — будет генерировать файлы с именем длиной 11 символов.

И ещё накопал информацию о наличии некоторых проблем при удалении ОЧЕНЬ БОЛЬШОГО количества файлов (порядка нескольких миллионов и более). Там может не помочь даже использование find — всё потихоньку затормаживается и виснет. Внезапно (tm) выясняется, следующее:

find, как и ls, работают через библиотеку fts(3), в которой есть баг — если ей обрабатывать большие каталоги и код работает от рута, она сильно жрет память и CPU. А если код работает не от рута, то не жрет и делает всё то же самое (ну, если прав хватает).
Ваш комментарий
адрес не будет опубликован

ХТМЛ не работает

Ctrl + Enter
Популярное