Как быстро скопировать с изменением имени много файлов?

cp $name $name2

/thread

машинка не новая и обычным cp её загружает ажно на целые сутки, а это не приемлемо...

по другому никак? cp самый быстрый алгоритм?

Попробуй rsync или tar/untar, а потом переименовывай. Есть вероятность, что будет быстрее, но не факт. Или с линками замутить что-то, не вариант?

напиши сам на сях :)

С линками не вариант, старые файлы постоянно стираются. tar/untar надо попробовать...

Обязательно, как только стану програмистом :)

Так вот же и повод. :)
Действительно, сэкономить тут можно только на вызовах cp, поэтому надо С мутить.
А обязательно ли кидать их все разом, нельзя ли по мере появления?

Кто ещё считает, что стартовый скор нужно опустить где-то до 5-10 см?

mmv

</thread>

Для пятидесяти двухметровых файлов cp, однозначно, быстрее срабатывает(

Хотя странно. По логике cp копирует файлы по одному, а tar блоками.

Возможно это уже фс тормозит. Попробуй тоже самое на xfs.

Кто ещё считает, что стартовый скор нужно опустить где-то до 5-10 см?

Я за.

с такой постановкой задачи есть только один выход - меняй тормозной bash на что-либо иное. Хотя-бы на простой /bin/sh (только учти, что часто /bin/sh это симлинк на bash). И да, намного увеличить скорость не получится - чудес не бывает, даже просто удалить/создать 2500К файлов - это не очень быстро.

soomrack

Возможно это уже фс тормозит. Попробуй тоже самое на xfs.

тогда уж райзер. xfs она с большими файлами вроде-бы получше. Ещё можно попробовать EXT2 (на журнал время тут много уйдёт, может профит и будет).

Там вобщем входные данные это jpeg из эвентов ZM. скрипт их собирает за сутки, именует по порядку и делает суточное видео.

Если разбивать на копирование по мере появления то как сохранить последовательность именования?

возможно, но менять фс, крайний вариант ибо рабочий сервер...

напиши сам

Обязательно, как только стану програмистом :)

Что бы писать скрипты, вовсе не надо быть программистом.

Так всё проще. Появление файла ловим с помощью inotifywait (из inotify-tools), событие close_write, делаем новое имя либо приклеивая номер к шаблону, либо по дате/времени, и пишем в каталог с соотв. датой в имени. Оно автоматом будет по суточным каталогам собираться. А изготовление видео по крону запускать.

О, спасибо за идею!

С линками не вариант

с симлинками - да.

открой маны на ln. если еще «другие» ссылки, о них и прочитай. однако, там ограничение - всё должно быть внутри одного тома.

тьфу ты...
* есть еще «другие»

тогда уж райзер. xfs она с большими файлами вроде-бы получше. Ещё можно попробовать EXT2 (на журнал время тут много уйдёт, может профит и будет).

Предпочитаю xfs. Разницы с рейзером относительно работы с кучей мелких файлов особой нет. B+ деревья.

То есть вместо копирования создать линки. Чисто теоретически насколько это ускорит процесс? и скушает ли их нормально ffmpeg?

тоесть симлинки

reiser быстрее с мелкими фалами работает

Чисто теоретически насколько это ускорит процесс?

Ускорит. Но немного (файлы-то мелкие).

и скушает ли их нормально ffmpeg?

Это будут обычные файлы. Почему бы ему их не съесть?

Предпочитаю xfs

Питание ни разу случайно не отключал (жмакнешь так ногой по кнопочке на UPS'е - и кирдык всей ФС)?

вообще-то, я про хардлинки, если ты не нашел в себе сил прочитать ман.

Чисто теоретически насколько это ускорит процесс?

какой процесс, теоретик?! при создании ссылок копирование не происходит.

и скушает ли их нормально ffmpeg

скушает.

Сорри, неправильно понял твой пост. Хардлинки хороший вариант.

какой процесс, теоретик?! при создании ссылок копирование не происходит.

Такой процесс, хочешь сказать что если я в скрипте напишу создание хардлинков на 2.500.000 файлов они создадутся за нулевое время?

reiser быстрее с мелкими файлами работает

тюнить надо уметь.

Предпочитаю xfs

Питание ни разу случайно не отключал (жмакнешь так ногой по кнопочке на UPS'е - и кирдык всей ФС)?

Можно в полночь и х*й в розетку засунуть, если розетку на матрас поставить.

они создадутся за нулевое время?

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

Читаю, решил спросить паралельно))

всё равно reiser лучше чем хфс! И пусть он свою русскую жену убил и сидит в рустюряге, рейзер лучший!

меняй тормозной bash на что-либо иное

Скачать ускоритель IO операций бесплатно без СМС

Мне видится вызов cp не такая ресурсоёмкая операция, что её может ускорить смена шелла. Или да?

Предпочитаю xfs

Питание ни разу случайно не отключал

Как-то у меня глючила мать, комп отрубался неожиданно в период от одной до 30 минут после загрузки, за те 2 дня пока я искал кто именно глючит было от 25 до 35 (уже не помню точно) таких падений. У меня там около 10 xfs разделов, ничего не умерло и ниодин файл не пострадал.

Но у тебя конечно иной опыт :-)

ты первый пост почитай - имя там в переменной шела. значит по одному копировать тс хочет. Не?

ты как-нить попробуй сравнить cp vs ln для каталога в 2500000 мелких файлов. Потом потрещим.

Кстати, у меня есть ~4000 директорий, в каждой из ~4000 файлов. Можно будет завтра (если не забуду) проверить.

не, это другое. Я про ОДИН каталг, где дох* файлов

Потом потрещим.

ооо, «иксперты» подтянулись. я гляжу, у тебя на руках есть какие-то результаты, чтобы так нескромно выпячивать своё чсв?
давай, поделись.

Скопировать меньше, чем весят файлы, не получится. rsync будет только медленнее, так как он ещё и хеш считает; tar/untar - зачем? Атрибуты и cp умеет сохранять.

хотел сделать тест, но пока пытался его сделать понял только одно - насколько здорово, что я живу в 2000х, а не в 70х и мне не надо пользоваться чистым sh с его убогим синтаксисом, у меня даже листание по истории в нём оказалось не настроено, короче я проклял всё и ниасилил тест, прости меня.
поэтому опровергнуть твои теории сможешь только ты сам, я таки думаю, что раскрытие переменной и вызов ср не будут отличаться в разных шеллах по скорости

откуда нам знать, что у тса за скрипт, и где там узкое место? Я говорил лишь о том, что баш очень медленный яп, и сложный скрипт на нем можно ускорить просто сменой языка. Не нравится шелл - пиши на питоне, перловке, или хоть на пхп - будет быстрее. А по первому посту видно, что там далеко не только ср, а еще какая-то НЕХ

На первый взгляд тормозить будет: 1. много входных данных 2. много копий 3. (если система достаточно старая) O(N) поиск каталоге 4. много fork/exec-ов

Соответственно бороться нужно по каждому направлению: 1. «инкрементальной» обработкой (find -newer или inotify) 2. ln/mv вместо cp 3. более новыми ФС или ручным раскладыванием по 3хэтажному дереву 4. встроенными ф-ями копирования (busybox, например)

Ну и после этого уже выбрасывать тормозные диски.

Там вобщем входные данные это jpeg из эвентов ZM. скрипт их собирает за сутки, именует по порядку и делает суточное видео.

А ZoneMinder разучился делать видео по ивентам?
У меня он почему-то и по дням раскладывал, и jpeg-и сохранял, и видео делал (используя ffmpeg), да еще и по дням это все сортировал.

Да, вот только мне нужно не десяти минутное видео, а суточное. + насколько я помню когда удаляешь эвент вместе с ним и видео удаляется.

Ну у меня как раз до х... 200 каталогов в которых много много файлов.

Нынешний вид.

#!/bin/bash
#Параметры даты и камеры для создания видео и проверка.
workdate=$1
cam=$2
if [ "Z"$1 = "Z" ]; then
       echo "Укажите Дату для создания записи"
       exit 1
fi
if [ "Z"$2 = "Z" ]; then
       echo "Укажите Камеру для создания записи"
       exit 1
fi
# путь до эвентов ZM
inpath="/video/${cam}"
diry=$(date -d "${workdate}" +%y)
dirm=$(date -d "${workdate}" +%m)
dird=$(date -d "${workdate}" +%d)
# Где хранить картинки (временно)
jpgpath="TEMP_PATH"
# Куда складывать готовые видеофайлы
videopath="VIDEO_PATH"
#Задание имени готового видеофайла
mydate=$(date -d "${workdate}" +%Y-%m-%d)
filename=${cam}-${mydate}.avi
#База данных ZM
zmdatabase="ZM_BASE"
zmuser="ZM_USER"
zmpass="ZM_PASS
#Говорим с чем работаем
echo workdate is ${mydate}
echo camera is ${cam}
#создание директорий
mkdir -p ${jpgpath} 2> /dev/null
mkdir -p ${videopath} 2> /dev/null
# Выборка нужных файлов из базы данных с проверкой на ненулевой размер и копированием во временную директорию
monid=`mysql -u ${zmuser} --password=${zmpass} ${zmdatabase} -s -e "select Id from Monitors where Name='${cam}';" | awk '{print($1);}'`
evid=`mysql -u ${zmuser} --password=${zmpass} ${zmdatabase} -s -e "select Id from Events where MonitorId='${monid}' order by Id;" |awk '{print($1);}'`
i=0

for n in ${evid}
do
    declare -i frn=`mysql -u ${zmuser} --password=${zmpass} ${zmdatabase} -s -e "select Frames from Events where Id='${n}';" |awk '{print($1);}'`
    for (( fr=1; fr<=9; fr++ ))
    do
      fn="00${fr}-capture.jpg"
      if [ `ls -l ${inpath}/${diry}/${dirm}/${dird}/.${n}/${fn} | awk '{print $5}'` -gt 0 ]; then
         i=$((i+1))
         p=$(printf %.8d $i)
         ln ${inpath}/${diry}/${dirm}/${dird}/.${n}/${fn} ${jpgpath}/${p}.jpg
      fi
    done
    for (( fr=10; fr<=99; fr++ ))
    do
      fn="0${fr}-capture.jpg"
      if [ `ls -l ${inpath}/${diry}/${dirm}/${dird}/.${n}/${fn} | awk '{print $5}'` -gt 0 ]; then
         i=$((i+1))
         p=$(printf %.8d $i)
         ln ${inpath}/${diry}/${dirm}/${dird}/.${n}/${fn} ${jpgpath}/${p}.jpg
      fi
    done
    for (( fr=100; fr<=${frn} ; fr++ ))
    do
      fn="${fr}-capture.jpg"
      if [ `ls -l ${inpath}/${diry}/${dirm}/${dird}/.${n}/${fn} | awk '{print $5}'` -gt 0 ]; then
         i=$((i+1))
         p=$(printf %.8d $i)
         ln ${inpath}/${diry}/${dirm}/${dird}/.${n}/${fn} ${jpgpath}/${p}.jpg
      fi
    done
done
#удаление файла с таким же именем как у создаваемого
rm ${videopath}/${filename} 2> /dev/null
#кодирование видео из картинок
ffmpeg -r 25 -an -i ${jpgpath}/%08d.jpg -vcodec mpeg4 ${videopath}/${filename}
#удаление временных файлов
rm ${jpgpath}/*.jpg 2> /dev/null

Время выполнения на одной камере 18 часов 36 минут... жесть конечно....