ขนาดบล็อกที่ดีสำหรับการโคลนดิสก์ด้วย diskdump (dd)


46

ฉันใช้ dd ในรูปแบบที่ง่ายที่สุดเพื่อโคลนฮาร์ดไดรฟ์:

dd if=INPUT of=OUTPUT

อย่างไรก็ตามฉันอ่าน manpage ที่ dd รู้จักพารามิเตอร์ blocksize มีค่าที่เหมาะสมที่สุดสำหรับพารามิเตอร์ blocksize ที่จะเพิ่มความเร็วของกระบวนการโคลนหรือไม่?


คำตอบ:


32

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- หนักฉันครั้งเดียวนิด ๆ หน่อย ๆ @ งาน


โปรดทราบว่ามาตรฐานนี้อาจมีลักษณะแตกต่างกันสำหรับการหมุนไดรฟ์และ ssds
Jiri

3
-1 นี่เกือบทั้งหมดขึ้นอยู่กับฮาร์ดไดรฟ์ของคุณ ค่อนข้างอธิบายขั้นตอนที่ใช้ในการรับค่าเหล่านี้เพื่อให้ OP สามารถทำซ้ำขั้นตอนเพื่อให้ได้ขนาดบล็อกที่เหมาะสมที่สุดสำหรับฮาร์ดไดรฟ์ของเขาเอง นอกจากนี้คุณยังไม่ได้แสดงรายการ 64k ในรายการผลลัพธ์ของคุณและผลลัพธ์ทั้งหมดที่ผ่านมา 1k นั้นเหมือนกันมากหรือน้อย
Micheal Johnson

@MichealJohnson รู้สึกอิสระที่จะแก้ไขโพสต์นี้และอธิบายถึงวิธีการสร้างตารางนั้นจากลิงก์ที่ให้ไว้และวางไว้ที่นี่ 64k เป็นค่าแรกที่ดูเหมือนว่าจะไม่มีการปรับปรุงเพิ่มเติมในแง่ของความเร็วและเป็นการจัดตำแหน่งตามธรรมชาติ และใช่มันชัดเจนว่าความเร็วที่วัดได้นั้นขึ้นอยู่กับฮาร์ดแวร์ที่ใช้ นี่เป็นเรื่องจริงเมื่อ 5 ปีก่อนและตอนนี้มันเป็นจริง
กิระ

1
ทำไมต้อง 64k สำหรับฉัน 2k ไม่ได้ให้การปรับปรุงใด ๆ เพิ่มเติมและดังนั้น 1k จึงเป็นค่าที่ดีที่สุดและเป็นแนวร่วมที่ 64k
Micheal Johnson

ขนาดบล็อกเปลี่ยนประสิทธิภาพของการ์ด SD หรือลดขนาดของการย้ายไฟล์โดยใช้ dd เป็น sdcard หรือไม่
Trismegistos

22

dd จะคัดลอกอย่างมีความสุขโดยใช้ BS ของสิ่งที่คุณต้องการและจะคัดลอกบล็อกบางส่วน (ในตอนท้าย)

โดยทั่วไปพารามิเตอร์ block size (bs) ดูเหมือนว่าจะกำหนดจำนวนหน่วยความจำที่ใช้ในการอ่านในก้อนจากดิสก์หนึ่งก่อนที่จะพยายามเขียนก้อนที่อื่น

หากคุณมี RAM จำนวนมากดังนั้นการทำให้ BS มีขนาดใหญ่ (แต่มีอยู่ใน RAM ทั้งหมด) หมายความว่าระบบย่อย I / O นั้นถูกใช้งานมากที่สุดโดยการอ่านและเขียนขนาดใหญ่อย่างหนาแน่น - ใช้ประโยชน์จาก RAM การทำให้ BS เล็กหมายถึงค่าใช้จ่าย I / O ที่เป็นสัดส่วนของกิจกรรมทั้งหมดเพิ่มขึ้น

แน่นอนในเรื่องนี้มีกฎหมายว่าด้วยผลตอบแทนลดลง การประมาณคร่าวๆของฉันคือขนาดบล็อกในช่วงประมาณ 128K ถึง 32M น่าจะให้ประสิทธิภาพเช่นค่าโสหุ้ยมีค่าน้อยเมื่อเทียบกับ I / O ธรรมดาและขนาดใหญ่ขึ้นจะไม่สร้างความแตกต่างมากนัก เหตุผลที่ขอบเขตล่างเป็น 128K ถึง 32M นั้นขึ้นอยู่กับระบบปฏิบัติการฮาร์ดแวร์และอื่น ๆ

ถ้าเป็นฉันฉันจะทำการทดลองสองสามครั้งเพื่อคัดลอก / โคลนโดยใช้ BS ที่ 128K และใช้อีกครั้ง (พูด) 16M หากมีใครเห็นคุณค่าได้เร็วขึ้นให้ใช้มัน ถ้าไม่ใช้ BS ที่เล็กกว่าของทั้งสอง


10

สำหรับผู้ที่จบลงที่นี่ผ่านทาง Google แม้ว่าการสนทนานี้จะค่อนข้างเก่า ...

โปรดทราบว่า dd นั้นโง่ด้วยเหตุผล: ยิ่งง่ายขึ้นเท่าไรก็จะยิ่งทำให้เสียน้อยลงเท่านั้น

รูปแบบการแบ่งพาร์ติชันที่ซับซ้อน (พิจารณาว่าเป็นฮาร์ดไดรฟ์ดูอัลบูตที่ใช้ LVM เพิ่มเติมสำหรับระบบ Linux) จะเริ่มดึงบั๊กออกจากงานไม้ในโปรแกรมเช่น Clonezilla ระบบไฟล์ที่ไม่ได้ต่อเชื่อมไม่ดีสามารถระเบิด ntfsclone sky-high

ระบบไฟล์ที่เสียหายที่โคลนเซกเตอร์ต่อเซกเตอร์นั้นไม่ได้แย่ไปกว่าของเดิม ระบบไฟล์ที่เสียหายหลังจาก "สมาร์ทสำเนา" ล้มเหลวอาจจะอยู่ในรูปขอโทษจริงๆ

หากมีข้อสงสัยให้ใช้ววววววววววววววววว การถ่ายภาพทางนิติวิทยาศาสตร์ต้องใช้การทำสำเนาตามเซกเตอร์ (อันที่จริงแล้วมันอาจต้องใช้เซกเตอร์มากกว่าที่คุณจะสามารถดึงออกมาได้ด้วย dd แต่นั่นเป็นเรื่องที่ยาว) มันช้าและน่าเบื่อ แต่มันจะทำให้งานเสร็จอย่างถูกต้อง

และทำความรู้จักกับตัวเลือก "conv = noerror, sync" เพื่อให้คุณสามารถโคลนไดรฟ์ที่เริ่มล้มเหลว - หรือทำให้ ISO จากซีดีที่มีรอยขีดข่วน ( ไอ ) โดยไม่ต้องใช้เวลาเป็นเดือน


อะไรsyncตัวเลือกทำอย่างไร หน้าคนพูดว่า: "use synchronized I/O for data and metadata". เรากำลังทำข้อมูลให้ตรงกันกับอะไร? นั่นอาจเป็นสิ่งที่แตกต่างกันมากมาย
sherrellbc

1
@sherrellbc ซิงค์เติมบล็อกอินพุตด้วยเลขศูนย์ถ้ามีข้อผิดพลาดในการอ่านดังนั้นข้อมูลออฟเซ็ตยังคงซิงค์กันอยู่
goetzc

9

อย่างที่คนอื่นพูดไม่มีขนาดบล็อกที่ถูกต้องในระดับสากล สิ่งที่ดีที่สุดสำหรับสถานการณ์หนึ่งหรือฮาร์ดแวร์ชิ้นหนึ่งอาจไร้ประสิทธิภาพอย่างยิ่งสำหรับอีกสถานการณ์หนึ่ง นอกจากนี้ขึ้นอยู่กับสภาพของดิสก์มันอาจจะดีกว่าที่จะใช้ขนาดบล็อกที่แตกต่างจากสิ่งที่ "ดีที่สุด"

สิ่งหนึ่งที่ค่อนข้างน่าเชื่อถือในฮาร์ดแวร์สมัยใหม่คือขนาดบล็อกเริ่มต้นที่ 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 / ศูนย์และเขียนลงดิสก์คุณต้องอ่านจากดิสก์และเขียนถึง / 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

ข้อแตกต่างที่สำคัญในกรณีนี้คือไฟล์ทดสอบเป็นไฟล์ที่เขียนโดยสคริปต์ อย่าชี้คำสั่งนี้ที่ไฟล์ที่มีอยู่มิฉะนั้นไฟล์ที่มีอยู่จะถูกเขียนทับด้วยข้อมูลแบบสุ่ม!

สำหรับฮาร์ดแวร์เฉพาะของฉันฉันพบว่า 128K เป็นขนาดบล็อกอินพุตที่ดีที่สุดบน HDD และ 32K นั้นดีที่สุดสำหรับ SSD

แม้ว่าคำตอบนี้จะครอบคลุมการค้นพบส่วนใหญ่ของฉัน แต่ฉันพบกับสถานการณ์นี้มากพอที่ฉันจะเขียนโพสต์บล็อกเกี่ยวกับเรื่องนี้: http://blog.tdg5.com/tuning-dd-block-size/คุณสามารถค้นหาข้อมูลเฉพาะเพิ่มเติมได้ ในการทดสอบที่ฉันทำที่นั่น

StackOverflow โพสต์นี้อาจมีประโยชน์เช่นกัน: dd: วิธีการคำนวณขนาดบล็อกที่เหมาะสม?


3

ใช่ แต่คุณจะไม่พบมันหากไม่มีการทดสอบมากมาย ฉันพบว่า 32M นั้นคุ้มค่าสำหรับการใช้งาน


1

การโคลนไดร์ฟสำหรับบูตเก่าเป็น ssd ใหม่บน sata ภายนอก (ssd ถึง ssd)

  • ใช้ linux Ubuntu 18.04.2 LTS 64 บิต
  • hp xw4600 (RAM 8GB, Intel Core 2 Quad Q6700 @ 2.66GHz 4c / 4t ไม่มี -HT)

การใช้ดิสก์ (เครื่องมือ)> รูปแบบ> การลบ ATA ที่ปลอดภัย (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 (เก่า; ดิสก์รายงานอัตราเฉลี่ยถัวเฉลี่ย 263 MB / s โดยมียอดใกล้เคียงกับ 270 MB / s - ไม่มีการทดสอบการเขียนเนื่องจากดิสก์ระบบ)
  • sdf: Crucial MX500, 500GB, CT500MX500SSD1 (รายงานดิสก์: อัตราเฉลี่ย rd / wr 284/262 MB / s และเวลาเข้าถึง 0.05ms โดยมี peaks ที่ประมาณ 290/270 MB / s)

ทดสอบการทำงาน:

$ 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

ยินดีต้อนรับสู่ Super User! ขอบคุณสำหรับคำตอบของคุณ แต่ฉันขอแนะนำให้คุณแก้ไขเพื่อรวมข้อมูลสรุป ในบรรดาผลลัพธ์ที่ยกมาทั้งหมดฉันพบว่ามันยากที่จะค้นหาว่าคำตอบที่แท้จริงของคุณคืออะไร! ไชโย
bertieb
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.