Хороший размер блока для клонирования диска с помощью diskdump (dd)

Я использую dd в простейшем виде для клонирования жесткого диска:

dd if=INPUT of=OUTPUT

Тем не менее, я прочитал на странице руководства, что dd знает параметр размера блока. Существует ли оптимальное значение для параметра размера блока, которое ускорит процедуру клонирования?

64k кажется хорошим выбором:

Results:

  no bs=        78s     144584+0 records
  bs=512        78s     144584+0 records
  bs=1k         38s     72292+0 records
  bs=2k         38s     36146+0 records
  bs=4k         38s     18073+0 records
  bs=5k         39s     14458+1 records
  bs=50k        38s     1445+1 records
  bs=500k       39s     144+1 records
  bs=512k       39s     144+1 records
  bs=1M         39s     72+1 records
  bs=5M         39s     14+1 records
  bs=10M        39s     7+1 records

(взято отсюда ).

это совпадает с моими собственными выводами относительно буферизации чтения / записи для ускорения io-тяжелой программы-конвертера, которую я когда-то использовал в @work.

ДД с радостью скопирует с помощью БС того, что вы хотите, и скопирует частичный блок (в конце).

По сути, параметр размера блока (bs), по-видимому, задает объем памяти, который использовался для чтения кусочка с одного диска перед попыткой записи этого кусочка на другой.

Если у вас много ОЗУ, то увеличение размера БС (но целиком и полностью в ОЗУ) означает, что подсистема ввода-вывода максимально используется при массовых операциях чтения и записи, используя ОЗУ. Уменьшение BS означает, что издержки ввода-вывода как доля от общей активности возрастают.

Конечно, в этом есть закон убывающей отдачи. Мое грубое приближение состоит в том, что размер блока в диапазоне от 128K до 32M, вероятно, даст такую ​​производительность, что накладные расходы будут маленькими по сравнению с обычным вводом / выводом, и увеличение их размера не будет иметь большого значения. Причина, по которой нижняя граница составляет от 128 КБ до 32 МБ, зависит от вашей ОС, аппаратного обеспечения и т. Д.

Если бы это был я, я бы провел несколько экспериментов, рассчитывая время копирования / клонирования, используя BS 128K и снова используя (скажем) 16M. Если кто-то заметно быстрее, используйте его. Если нет, то используйте меньший BS из двух.

Для тех, кто попадает сюда через Google, даже если это обсуждение немного устарело ...

Имейте в виду, что dd глуп по какой-то причине: чем проще, тем меньше способов его испортить.

Сложные схемы разбиения (например, жесткий диск с двойной загрузкой, который дополнительно использует LVM для своей системы Linux) начнут вытаскивать ошибки из дерева в таких программах, как Clonezilla. Плохо размонтированные файловые системы могут взорвать ntfsclone до небес.

Поврежденная файловая система, клонированная посекторно, не хуже оригинала. Поврежденная файловая система после неудачной «умной копии» может быть в ДЕЙСТВИТЕЛЬНО жалкой форме.

В случае сомнений используйте dd и отправляйтесь на судебную экспертизу. Для работы с криминалистическими изображениями требуются посекторные копии (на самом деле, для этого может потребоваться больше секторов, чем вы сможете выполнить с помощью dd, но это долгая история). Это медленно и утомительно, но это сделает работу правильно.

Кроме того, ознакомьтесь с опциями «conv = noerror, sync», чтобы вы могли клонировать диски, которые начинают выходить из строя - или создавать ISO-образы с поцарапанных ( кашляющих ) компакт-дисков - без того, чтобы это занимало месяцы.

Как уже говорили другие, не существует универсально правильного размера блока; то, что оптимально для одной ситуации или одного устройства, может быть ужасно неэффективно для другой. Кроме того, в зависимости от работоспособности дисков может оказаться предпочтительным использовать другой размер блока, чем тот, который является «оптимальным».

Одна вещь, которая довольно надежна на современном оборудовании, состоит в том, что размер блока по умолчанию в 512 байт, как правило, почти на порядок медленнее, чем более оптимальная альтернатива. Когда я сомневался, я обнаружил, что 64K - довольно солидный современный стандарт. Хотя 64K обычно не является оптимальным размером блока, по моему опыту, он намного эффективнее, чем по умолчанию. 64K также имеет довольно солидную историю надежной производительности: вы можете найти сообщение из списка рассылки Eug-Lug около 2002 года, рекомендующее размер блока 64K, здесь: http://www.mail-archive.com/eug- lug@efn.org/msg12073.html

Для определения оптимального размера выходного блока я написал следующий скрипт, который тестирует написание тестового файла 128M с dd в диапазоне разных размеров блока, от 512 байтов по умолчанию до максимум 64M. Имейте в виду, этот скрипт использует dd внутри, поэтому используйте его с осторожностью.

dd_obs_test.sh:

#!/bin/bash

# Since we're dealing with dd, abort if any errors occur
set -e

TEST_FILE=${1:-dd_obs_testfile}
TEST_FILE_EXISTS=0
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=1; fi
TEST_FILE_SIZE=134217728

if [ $EUID -ne 0 ]; then
  echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi

# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'

# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
  # Calculate number of segments required to copy
  COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))

  if [ $COUNT -le 0 ]; then
    echo "Block size of $BLOCK_SIZE estimated to require $COUNT blocks, aborting further tests."
    break
  fi

  # Clear kernel cache to ensure more accurate test
  [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches

  # Create a test file with the specified block size
  DD_RESULT=$(dd if=/dev/zero of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync 2>&1 1>/dev/null)

  # Extract the transfer rate from dd's STDERR output
  TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')

  # Clean up the test file if we created one
  if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi

  # Output the result
  printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done

Посмотреть на GitHub

Я тестировал этот сценарий только в системе Debian (Ubuntu) и в OSX Yosemite, поэтому, возможно, потребуется некоторая настройка для работы с другими версиями Unix.

По умолчанию команда создаст тестовый файл с именем dd_obs_testfile в текущем каталоге. Кроме того, вы можете указать путь к пользовательскому тестовому файлу, указав путь после имени скрипта:

$ ./dd_obs_test.sh /path/to/disk/test_file

Выходные данные сценария представляют собой список протестированных размеров блоков и их соответствующих скоростей передачи, например:

$ ./dd_obs_test.sh
block size : transfer rate
       512 : 11.3 MB/s
      1024 : 22.1 MB/s
      2048 : 42.3 MB/s
      4096 : 75.2 MB/s
      8192 : 90.7 MB/s
     16384 : 101 MB/s
     32768 : 104 MB/s
     65536 : 108 MB/s
    131072 : 113 MB/s
    262144 : 112 MB/s
    524288 : 133 MB/s
   1048576 : 125 MB/s
   2097152 : 113 MB/s
   4194304 : 106 MB/s
   8388608 : 107 MB/s
  16777216 : 110 MB/s
  33554432 : 119 MB/s
  67108864 : 134 MB/s

(Примечание: единица измерения скорости передачи данных зависит от ОС)

Чтобы проверить оптимальный размер блока чтения, вы можете использовать более или менее тот же процесс, но вместо чтения из / dev / zero и записи на диск вы будете читать с диска и записывать в / dev / null. Сценарий для этого может выглядеть так:

dd_ibs_test.sh:

#!/bin/bash

# Since we're dealing with dd, abort if any errors occur
set -e

TEST_FILE=${1:-dd_ibs_testfile}
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=$?; fi
TEST_FILE_SIZE=134217728

# Exit if file exists
if [ -e $TEST_FILE ]; then
  echo "Test file $TEST_FILE exists, aborting."
  exit 1
fi
TEST_FILE_EXISTS=1

if [ $EUID -ne 0 ]; then
  echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi

# Create test file
echo 'Generating test file...'
BLOCK_SIZE=65536
COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))
dd if=/dev/urandom of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync > /dev/null 2>&1

# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'

# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
  # Clear kernel cache to ensure more accurate test
  [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches

  # Read test file out to /dev/null with specified block size
  DD_RESULT=$(dd if=$TEST_FILE of=/dev/null bs=$BLOCK_SIZE 2>&1 1>/dev/null)

  # Extract transfer rate
  TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')

  printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done

# Clean up the test file if we created one
if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi

Посмотреть на GitHub

Важным отличием в этом случае является то, что тестовый файл - это файл, который записывается скриптом. Не указывайте эту команду на существующий файл, иначе существующий файл будет перезаписан случайными данными!

Для моего конкретного оборудования я обнаружил, что 128 КБ был самым оптимальным размером входного блока на жестком диске, а 32 КБ был наиболее оптимальным на SSD.

Хотя этот ответ покрывает большинство моих выводов, я сталкивался с такой ситуацией достаточно много раз, когда писал об этом в блоге: http://blog.tdg5.com/tuning-dd-block-size/ Вы можете найти больше подробностей на тестах я там проводил.

Этот пост StackOverflow также может быть полезен: dd: Как рассчитать оптимальный размер блока?

Да, но вы не найдете его без большого количества испытаний. Я обнаружил, что 32M является хорошим значением для использования.

клонирование старого загрузочного диска в новый ssd на внешнем sata (ssd to ssd)

• используя Linux Ubuntu 18.04.2 LTS 64bit
• hp xw4600 (8 ГБ ОЗУ, Intel Core 2 Quad Q6700 @ 2,66 ГГц, 4c / 4t без HT)

используя Диски (инструмент)> формат> ATA Secure Erase (2 минуты)

$ lsblk -l /dev/sd?
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda    8:0    0 119,2G  0 disk 
sda1   8:1    0 119,2G  0 part /
sdb    8:16   0   2,7T  0 disk 
sdc    8:32   0   2,7T  0 disk 
sdd    8:48   0  12,8T  0 disk 
sde    8:64   0   2,7T  0 disk
sdf    8:80   1 465,8G  0 disk 

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

$ sudo fdisk -l /dev/sdf
Disk /dev/sdf: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

• sda: Kingston SSD (старый; Disks сообщает о средней скорости записи 263 МБ / с с пиками, близкими к 270 МБ / с - тест записи не выполняется из-за системного диска)
• sdf: Crucial MX500, 500 ГБ, CT500MX500SSD1 (отчеты дисков: средняя скорость чтения / записи 284/262 МБ / с и время доступа 0,05 мс, с пиками около 290/270 МБ / с)

Тестовые прогоны:

$ sudo dd if=/dev/sda of=/dev/sdf
250069680+0 records in
250069680+0 records out
128035676160 bytes (128 GB, 119 GiB) copied, 3391,72 s, 37,7 MB/s
#       --vvvvv--                            *********
$ sudo dd bs=1M if=/dev/sda of=/dev/sdf
122104+1 records in
122104+1 records out
128035676160 bytes (128 GB, 119 GiB) copied, 473,186 s, 271 MB/s
#                                            *********  ********

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

128035676160 bytes (128 GB, 119 GiB) copied, 472,797 s, 271 MB/s