Я хочу точно скопировать весь диск из /dev /sda в /dev /sdb, поэтому я хотел бы использовать команду dd в Linux, но меня смущают две опции: bs и sync .
dd if =/dev/sda of =/dev/sdb bs = 4096 conv = notrunc, noerror, sync
Должен ли я добавить опцию sync как предложил wiki.archlinux.org?
Должен ли я установить bs=16384kB в качестве размера дискового кэша, а не большее число, чтобы максимизировать скорость?
Должен ли я добавить опцию синхронизации, как предложил wiki.archlinux.org?
Если вы собираетесь использовать опцию conv=noerror , то вам лучше использовать с ней conv=sync , иначе вы можете получить бесполезную резервную копию.
По справочной странице Linux
Each CONV symbol may be:
...
sync
pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs
Эта опция, которая может добавить заполнение, необходима при указании noerror или опции "продолжить после ошибок чтения". Контроллер диска не предоставляет данные сектора для входного буфера, когда происходит жесткая (то есть неустранимая) ошибка чтения. Если dd завершается с такой ошибкой (как это обычно бывает), то нехватка данных не является проблемой.
Однако, когда указано "продолжить после ошибок чтения", возникает проблема с отсутствием данных. Если входной буфер не дополняется для учета сектора (ов), который является / нечитаемым, то записываемые последующие данные будут смещены относительно надлежащих секторов, в которые они должны быть записаны. Или, если последующие данные пропущены по целевым секторам, соответствующим ошибкам (или произвели поиск (на языке dd ) в соответствующем секторе), то данные мусора в этих пропущенных секторах будут обрабатываться как копии исходных данных.
Если вы использовали dd для копирования блоков с целым порядковым номером, заполнение может не потребоваться для обнаружения или учета отсутствующих блоков. Нельзя предположить, что сырые секторы диска имеют такую интегральную порядковую нумерацию и требуют заполнения, чтобы попытаться сохранить целостность скопированной файловой системы.
Обратите внимание, что есть две опции sync , доступные с dd.
Один - conv=sync а другой - iflag=sync . У них разные значения.
Должен ли я установить bs = 16384kB в качестве размера дискового кэша, а не большее число, чтобы максимизировать скорость?
Какое "большее число" вы имеете в виду?
Параметр bs , size block, никак не связан с размером кеша (хотя я не уверен, к какому кешу вы обращаетесь).
16 МБ, вероятно, излишне, так как может даже не хватить памяти DMAable для блокировки. Существуют некоторые тесты производительности для изменения размера блока, и те, которые я видел, такие как этот , подтверждают мое подозрение, что существует размер уменьшающегося (или, по крайней мере, не больше) возврата, который, кажется, составляет около 512 КБ.
Классическим значением для bs при копировании жесткого диска был размер дорожки в байтах (или num_of_sectors_per_track * 512 байтов). Но поскольку современные жесткие диски используют зонированную битовую запись и изменяют плотность записи, не существует фиксированного (или известного в этом отношении) "количества секторов на дорожку". Типичная опубликованная спецификация "63 сектора на дорожку" на современных дисках представляет собой просто численное удобство.
Не то чтобы dd не справился с этой задачей, но вы можете рассмотреть возможность использования dd_rescue, если он доступен. Он дает возможность лучше справляться с любыми поврежденными секторами и обеспечивает лучшую работу по предоставлению информации о состоянии во время копирования. Синтаксис немного отличается:
# dd_rescue [options] infile outfile
# using a 1M block size allows dd_rescue to adjust it's reads/writes to the limits of the OS buffer
dd_rescue -b 1M /dev/sda /dev/sdb
#sample of the status
dd_rescue: (info): Using softbs=1048576, hardbs=4096
dd_rescue: (info): ipos: 1048576000.0k, opos: 1048576000.0k, xferd: 1048576000.0k
errs: 0, errxfer: 0.0k, succxfer: 1048576.0k
+curr.rate: 107936kB/s, avg.rate: 107268kB/s, avg.load: 98.6%
>-----------------------------------------< 100% ETA: 0:00:00
Вы можете обнаружить, что увеличение скорости клона немного менее важно, чем информирование о том, сколько времени занимает процесс.
Имейте в виду, что начальные средние скорости передачи могут вводить в заблуждение, поскольку первые 50 ГБ или около того диска с вращающимся дисководом на 30% быстрее, чем остальные. Он копирует с физически более коротких дорожек на внутренней стороне диска и замедляется по мере того, как дорожки становятся длиннее. Конечно, вы не увидите этого для SSD.
bs означает, что n b (байты) читаются и записываются каждый раз. Это обозначает размер блока. bs не обязательно влияет на размер входного блока ibs или размер выходного блока obs .
sync говорит процессу подождать, пока все данные будут правильно записаны на диск, прежде чем перейти к следующему блоку. Обычно лучше обеспечить целостность данных и избежать потери данных в случае сбоя питания (например, отключение диска, как только он закончил запись данных), но это происходит медленнее.
Без sync процесс копирования в целом быстрее, и устройство может выполнить запись раньше, чем с включенной sync , но вы можете заметить, что, когда информация полностью скопирована, фактически диск может все еще записывать информацию из своего кэша в реальную поддержку. Это часто хорошо для жестких дисков или когда вы не планируете отключать устройство, как только копия будет сделана.
Проще говоря:
sync → ожидание информации, которая будет полностью записана в реальную поддержку.sync → отправить информацию. на устройство и пусть он обрабатывает реальную запись.Вы можете ускорить процесс (немного) с включенной опцией sync , используя большой размер блока bs чтобы избежать беспрепятственного доступа к диску между небольшими промежутками времени и тем самым замедлить весь процесс.
Я всегда использовал dd без опции sync и у меня никогда не возникало никаких проблем, просто подождите, пока информация будет полностью записана, прежде чем извлекать любое устройство.