Как рассчитать время копирования команды dd с диска 2ТБ на диск 2ТБ разных моделей

bs=512 это win :)

А как сейчас модно делать? bs=4096?

Отрабатывает он уже начиная с 19:35 04.10.2014

а теперь подумай о ценности этой информации для окружающи

Потом соберись с мыслями, и последовательно изложи свою тему, без этого безграмотного потока сознания

Двое суток примерно. А на SAS — раза в 3 поменьше.

4M

Mdadm синкает рейд1 из 2 3тб дисков часов 8. Так что рассчитывай на 4 часа.

Можешь попробовать приостановить процесс через Ctrl+z, после через fg или bg пустить его в фоне.

А откуда такая цифра?

Ни один из ответов не является правильным))) никаких двое суток он не копировался. Недавно вот закончилось копирование))) 73897 секунд копировалось на скорости 27.1 МБ в сек. Знатоки блин)))) А аналитически как рассчитать так никто видимо и не знает, печально)

А аналитически как рассчитать так никто видимо и не знает, печально)

Аналитически — легко

t = V / v

Подозреваю, тебе надо численно, а не аналитически.

Mdadm синкает рейд1 из 2 3тб дисков часов 8

Разве что со скоростью по умолчанию.

На самом деле между 1М и 10М особой разницы не будет.

Я бы вообще pv использовал: и индикация прогресса, и параметры I/O определять не нужно.

Надо было делать так:

dd if=/dev/sdb bs=4M | pv -s `blockdev --getsize64 /dev/sdb` | dd bs=4M of=/dev/sdc

sudo iotop

Зачем в таком случае вообще dd?

Прост))))

bs=4194304

Ну то есть 4ре килобайта, по размеру сектора современного накопителя?

у тебя ошибка на три порядка, иди проспись

В чём моя ошибка? 4096 байт.

bs=512

Во-первых это дефолт, во-вторых это будет ООООЧЕНЬ медленно. bs в идеале должен быть соразмерен дисковому кэшу. То есть 4, 8, 16, 32 и т.д. мегабайта(!) - это ок. 512 байт - это фэйл.

4194304 байт

bs ставь размеру кэша диска 16M, 32M, 64M, используй pv, bar, dcfldd отображают ход процесса

Запускаешь dd, потом делаешь kill -USR1 $PIDOF_DD и смотришь текущую скорость копирования, расчитываешь время.

На каком основании нужно ставить bs соразмерно кэшу, а не размеру кластера?

Вот смотри - сначала с первого диска читается один сектор, потом он пишется на второй, первый в это время ничего не делает, плюс оверхед на общение с контроллером, обработку прерывания

что за «кластер»? это что-то из убогой ntfs?

И да, по моему опыту, копирование 1Тб диска длится около 3 часов, bs выставляется в несколько мегабайт

чем больше блок, тем меньше процессорного оверхеда. чё тут неясно?

Это 4 гб. Я не понял, в чём я не прав. Я вёл речь про 4кб. блок.

А кеш в этом случае как может помочь?

это 4 мегабайта

а не размеру кластера?

)))

наблюдение за работой dd в реальном времени

watch -n 1 killall -USR1 dd 

В общем я уже запутался, в чём я не прав, и где я ошибся. Вы может процитируете меня?

главное в рассчётах помнить, что диски на крае и у шпинделя читается с разной скоростью.

измерь запись в начале, потом в конце, потом усереднить и апроксимировать.

а чё, рассчитать исходя из радиуса там не?

— «Я смотрю my little pony уже несколько лет» © DALDON, 2014

а чё, рассчитать исходя из радиуса там не?

можно и так

Подскажите, пожалуйста, как аналитически рассчитать время копирования

никак. Только интерполяцией, т.е. если за сутки 1Т скопировался, то второй тоже сутки будет примерно.

И да, bs нужно ставить как можно больше. Однако если он больше кеша, то это не ускоряет. Лично я ставлю всегда 16М.

Но вообще лично я переношу данные tar'ом. Типа того:

tar -C dir1 -czf - *| tar -C dir2 -xzvvf -

Потому что после dd всё рано запарно, например UUID'ы тоже клонируются, а они вообще говоря должны быть уникальными. Да и долго воздух гонять туда-сюда.

а чё, рассчитать исходя из радиуса там не?

не. Там и плотность записи разная, что-бы выровнять.

потом по любому основное время тратится на поиск дорожки. Прочитать это всего один оборот, а вот сдвинуть на соседнюю, и дождаться пока оно успокоится и что дорожка точно соседняя, и выехать на середину — это больше оборота, и намного.

tar -C dir1 -czf - *| tar -C dir2 -xzvvf -

А чем это лучше простого cp с ключами --archive и --recursive? И зачем там сжатие гзипом?

измерь запись в начале, потом в конце, потом усереднить и апроксимировать.

Обычно средняя в 1.3—1.5 ниже максимальной. Т.е. достаточно ориентироваться на hdparm -t /dev/sd? и уменьшить на треть.

Для современных винтов 2Тб перегнать — это 6-9 часов.

...

Блин, я помню времена, когда винт на винт целиком за минуту копировался :D

А чем это лучше простого cp с ключами --archive и --recursive?

tar лучше работает с разными хитрыми хардлинками/симлинками/именами/правами/датами

tar ещё даёт возможность сделать бекап, т.е. копировать вовсе не обязательно с источника на приёмник, можно через третий носитель, либо через тройник в третий послать

Ну и у tar'а вообще больше разных полезных фич. Ну многотомные архивы например. Как ты командой cp будешь на нескольких флешках информацию таскать?

И зачем там сжатие гзипом?

сжатие не мешает и не тормозит. Процессор по любому работает быстрее копирования. Поможет если захотелось бекап, или если по сети гнать (у меня обычно сжатие по ssh отключено, но тут объём большой).

Блин, я помню времена, когда винт на винт целиком за минуту копировался :D

ты что-то путаешь. Раньше диски были конечно маленькие, но скорость у них тоже была маленькой. Явно не за минуту.

32 гб диск с бэд блоками я переносил на другой диск в 32 гб за 3 минуты.

Ага:

mdadm -B /dev/md4 -n 2 -l 1 -R /dev/sdc missing
mdadm /dev/md4 -a /dev/sdd