LINUX.ORG.RU
Форум — Admin  

Скорость копирования

 


0

1

пытаюсь сделать образ диска с помощью dd. если написать просто dd if of скорость чтения 9мб скорость записи 9мб. делаю dd if of bs=1G чтение 150мб запись 100мб. Но в первом случае чтение и запись происходит одновременно, а вот втором по очереди т.е пока оно читает запись простаивает, пока пишет - новые даные не читаются. Как сделать чтобы и скорость была нормальная и происходил процесс одновремено?

Перемещено hobbit из general

★

Последнее исправление: hobbit (всего исправлений: 1)
← Потрясающий косяк в UNISON
Кто уже сталкивался с 166 указом? Он для вообще всего софта? →

Очевидно если дефолтный блок в 512б слишком мало, а в 1Гб слишком много, то попробуй что нибудь между ними. 4Мб отлично подходит большинству сценариев.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 2)
Ответ на: комментарий от anonymous

А можно не использовать dd и иметь оптимальные параметры

От задачи зависит. cat для текстовых файликов, dd для бинарных образов.

всегда, когда их правильно определяет ядро.

Т.е. почти никогда. Хз почему так, но ссд предпочитают иметь огромный физический блок 256К-4М при маленьком логическом 512-4К. Надо записать 4К? Пишем целый блок и не паримся. И всё это в ftl, полностью скрыто от системы. Наружу он представляет мелкие блоки.

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

От задачи зависит. cat для текстовых файликов, dd для бинарных образов.

Тебе так деды сказали? cat, pv — для всего, что нужно тупо скопировать из файла в файл. Блочное устройство или регулярный файл — неважно.

Т.е. почти никогда

Почти всегда. А если устройство репортит какую-то дичь, то обычно выбираются более разумные параметры. Посмотреть можешь в /sys/block/.

И всё это в ftl, полностью скрыто от системы. Наружу он представляет мелкие блоки.

Если при проектировании накопителя так решили, то пусть так и будет. В целом это проблемы инженеров, которые так решили. Заявленную производительность ты получишь.

anonymous
()

Оно и в первом по очереди, просто куски такие маленькие что ты не замечаешь этого. Но bs=1G тратит слишком много памяти. Поставь 1M - будет скорость уже максимально возможная и не надо будет гигабайт данных в памяти хранить.

Если хочешь параллельно чтение и запись то сделай dd if= bs= | dd of= bs= (два dd через конвеер).

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

Вот в этом случае использование dd как раз оправдано. Это уже не совсем «тупо скопировать». Из частого ещё можно упомянуть изменение порядка байтов.

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

Блочное устройство или регулярный файл — неважно.

Как раз таки может быть важно. cat может решить что что то нужно перекодировать или воспринять как спецсимволы. И нужно очень хорошо понимать как это работает. dd может и избыточен для простого копирования, но по крайней мере он точно сделает это бит-в-бит.

С pv я вообще не знаком. cp разумеется ороший выбор, но он просто копирует, а dd хорош для блочных устройств и образов за счёт дополнительного функционала (если ты знаешь зачем тебе это нужно).

Заявленную производительность ты получишь.

В случае медленного флеша - блоки от 0,5 до 4М стабильно дают максимальный результат, а стандартный 512б-4К обычно имеют нюансы.

Блин, да вспомните все эти тесты скорости мелкими и большими блоками! Там всегда просадка на мелких! Этого же легко избежать сразу отдавая накопителю данные большими независимо от того, что там решит дисковый кеш ядра.

kirill_rrr ★★★★★
()

Кстати, для hdd с черепичной записью, которые так сильно любят производить и продавать производители, искуственное завышение блока записи это тоже хорошо.

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

cat может решить что что то нужно перекодировать или воспринять как спецсимволы

Попробуй читать документацию.

С pv я вообще не знаком

Знакомство занимает минуту, полезнейшая утилита. Можно использовать с dd для более внятной индикации прогресса.

Блин

Блин, да плевать на это всё. Поинт в том, что cat/pv/cp никогда не будут медленнее dd, какой бы ты там размер блока ни задавал руками.

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

Поинт в том, что cat/pv/cp никогда не будут медленнее dd, какой бы ты там размер блока ни задавал руками.

Не совсем верно. Тактика с правильным размером блока всё таки даёт номинальный результат.

root@raspberrypi:~# lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda             8:0    0 931,5G  0 disk 
└─data2-data2 254:0    0   1,8T  0 lvm  /media/data2
sdb             8:16   1   7,2G  0 disk [SWAP]
sdc             8:32   0 931,5G  0 disk /media/data
sdd             8:48   0 931,5G  0 disk 
└─data2-data2 254:0    0   1,8T  0 lvm  /media/data2
sde             8:64   1 120,1M  0 disk 
└─sde1          8:65   1 119,1M  0 part 
mmcblk0       179:0    0  59,6G  0 disk 
├─mmcblk0p1   179:1    0    64M  0 part 
├─mmcblk0p2   179:2    0   8,1G  0 part 
├─mmcblk0p3   179:3    0   8,1G  0 part /
└─mmcblk0p4   179:4    0  43,4G  0 part /home
root@raspberrypi:~# dd if=/dev/sde of=/tmp/test.img bs=512
246016+0 записей получено
246016+0 записей отправлено
 скопировано 125960192 байта (126 MB), 11,325 c, 11,1 MB/c
root@raspberrypi:~# cp /tmp/test.img /dev/sde
root@raspberrypi:~# time $( cp /tmp/test.img /dev/sde && sync )

real    0m46.975s
user    0m0.000s
sys     0m0.810s
root@raspberrypi:~# time $( dd if=/tmp/test.img of=/dev/sde bs=512 && sync )
246016+0 записей получено
246016+0 записей отправлено
 скопировано 125960192 байта (126 MB), 85,0285 c, 1,5 MB/c

real    1m25.351s
user    0m0.310s
sys     0m4.200s
root@raspberrypi:~# time $( dd if=/tmp/test.img of=/dev/sde bs=1K && sync )    
123008+0 записей получено
123008+0 записей отправлено
 скопировано 125960192 байта (126 MB), 81,2027 c, 1,6 MB/c

real    1m21.558s
user    0m0.140s
sys     0m3.230s
root@raspberrypi:~# time $( dd if=/tmp/test.img of=/dev/sde bs=4K && sync )
30752+0 записей получено
30752+0 записей отправлено
 скопировано 125960192 байта (126 MB), 46,9155 c, 2,7 MB/c

real    0m46.993s
user    0m0.420s
sys     0m0.550s
root@raspberrypi:~# time $( dd if=/tmp/test.img of=/dev/sde bs=8K && sync )
15376+0 записей получено
15376+0 записей отправлено
 скопировано 125960192 байта (126 MB), 46,7017 c, 2,7 MB/c

real    0m46.750s
user    0m0.000s
sys     0m0.890s
root@raspberrypi:~# time $( dd if=/tmp/test.img of=/dev/sde bs=32K && sync )
3844+0 записей получено
3844+0 записей отправлено
 скопировано 125960192 байта (126 MB), 46,7606 c, 2,7 MB/c

real    0m46.918s
user    0m0.330s
sys     0m0.470s
root@raspberrypi:~# time $( dd if=/tmp/test.img of=/dev/sde bs=16K && sync )
7688+0 записей получено
7688+0 записей отправлено
 скопировано 125960192 байта (126 MB), 46,6257 c, 2,7 MB/c

real    0m46.676s
user    0m0.010s
sys     0m0.830s
root@raspberrypi:~#
kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

Кстати, обратите внимание на другую мою штуку: 

sdb             8:16   1   7,2G  0 disk [SWAP]

Это 8Гб флешка в роли свопа. Если вы когда нибудь так делали, то должны знать насколько это кошмарное решение. Проблема именно в диких задержках записи, стопорящих вообще всё. zswap сам по себе не способен это предотвратить, только отсрочить и снизить частоту трешака. Но вот очередь в 64 страницы сброса в своп - делает трешка настолько редким, что я даже сам забываю что в данный момент Пи3 работает в аварийном режиме по временной схеме и браузером нужно пользоваться акуратно.

И дело тут именно в размере блоков записи на данный конкретный диск.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Окей, убедил. Я никогда не утруждал себя нормальным сравнением, просто эпизодические наблюдения в редких случаях, когда мне надо записать образ на флэшку, плюс считывание целиком блочных устройств, чтобы проверить примерную скорость или даже просто посмотреть температуру. Видимо, не всегда всё так просто.

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

Поинт в том, что cat/pv/cp никогда не будут медленнее dd

Будут:

[root@fedora-virt ~]# echo 1 >/proc/sys/vm/drop_caches
[root@fedora-virt ~]# time head -c 1073741824 /dev/vda >/dev/null

real    0m8.105s
user    0m0.167s
sys     0m0.706s
[root@fedora-virt ~]# echo 1 >/proc/sys/vm/drop_caches
[root@fedora-virt ~]# time dd if=/dev/vda of=/dev/null bs=4M iflag=direct count=256
256+0 records in
256+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.25737 s, 330 MB/s

real    0m3.268s
user    0m0.003s
sys     0m0.065s

Иногда лучше не писать глупости. Особенно если не впетриваешь, как эта магия с кэшами, постраничным и опережающим чтением, мержингом запросов, ожиданием в очереди и прочим работает.

no-dashi-v2 ★★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от annulen

Наткнулся на такую штуку в поиске, может пригодится: https://github.com/opencoff/fastdd

Добавлю в копилочку:

dataman ★★★★★
()
← Потрясающий косяк в UNISON
Admin
Кто уже сталкивался с 166 указом? Он для вообще всего софта? →