dd conv = sync, noerror ทำอะไร


39

ดังนั้นเมื่อมีการเพิ่มconv=sync,noerrorจะมีความแตกต่างเมื่อทำการสำรองข้อมูลทั้งฮาร์ดดิสก์ลงในไฟล์ภาพ? คือconv=sync,noerrorความต้องการเมื่อทำสิ่งที่นิติเวช? ถ้าเป็นเช่นนั้นทำไมถึงมีการอ้างอิงกับ linux fedora?

แก้ไข:

ตกลงดังนั้นถ้าฉันทำ dd โดยไม่มีconv=sync,noerrorและddพบข้อผิดพลาดในการอ่านเมื่ออ่านบล็อก (ลองขนาด 100M), dd จะข้ามบล็อก 100M และอ่านบล็อกถัดไปโดยไม่ต้องเขียนอะไรเลย ( dd conv=sync,noerrorเขียนค่าศูนย์ถึง 100M ของเอาต์พุต) ?)?

และถ้าเป็นกัญชาเดิมฮาร์ดดิสก์และไฟล์ที่ส่งออกแตกต่างกันถ้าทำได้โดยไม่ต้องconv=sync,noerror? หรือนี่เป็นเฉพาะเมื่อเกิดข้อผิดพลาดในการอ่าน?


3
โหวตขึ้นสำหรับคำถาม "Is conv = sync, noerror ต้องการเมื่อทำสิ่งนิติวิทยาศาสตร์หรือไม่?"
nergeia

คำตอบ:


44

conv=syncบอกddให้บล็อกแต่ละบล็อกไปทางซ้ายด้วยค่า Null ดังนั้นหากเกิดข้อผิดพลาดบล็อกเต็มไม่สามารถอ่านได้ความยาวเต็มของข้อมูลดั้งเดิมจะถูกเก็บรักษาไว้แม้ว่าข้อมูลทั้งหมดจะไม่สามารถรวมอยู่ในภาพได้ . อย่างน้อยที่สุดคุณก็รู้ได้ว่าความเสียหายของข้อมูลเป็นอย่างไรซึ่งอาจให้เบาะแสทางกฎหมายแก่คุณและหากคุณไม่สามารถถ่ายภาพได้เนื่องจากบล็อกไม่ดีหรืออะไรก็ตามคุณไม่สามารถวิเคราะห์ข้อมูลใด ๆ ได้ บางอย่างดีกว่าไม่มีเลย

conv=sync,noerrorมีความจำเป็นเพื่อป้องกันddการหยุดข้อผิดพลาดและดำเนินการถ่ายโอนข้อมูล conv=syncส่วนใหญ่ไม่มีความหมายโดยไม่มี noerror

http://linuxcommand.org/man_pages/dd1.html

http://vlinux-freak.blogspot.com/2011/01/how-to-use-dd-command.html


1
คำถาม: ถ้าไม่มี dd โดยไม่มี conv = sync, noerror แฮชของฮาร์ดดิสก์และไฟล์รูปภาพต่างกันหรือไม่?
dding

นอกจากนี้หากพบข้อผิดพลาดในการอ่านมันหยุดลงในขณะนั้นหรือไม่
dding

3
ตัวเองไม่ได้แฮไม่งั้นคุณกำลังคิดเรื่องเครื่องมือเช่น dcflDD forensicswiki.org/wiki/Dcflddหรือไม่? ในทางทฤษฎีแล้วการแฮชของดิสก์และแฮชของภาพควรเหมือนกันตราบใดที่เครื่องมือคำนวณแฮชพบข้อผิดพลาดในลักษณะเดียวกัน
Frank Thomas

37

dd conv=sync,noerror(หรือconv=noerror,sync) ทำให้ข้อมูลของคุณเสียหาย

ขึ้นอยู่กับข้อผิดพลาดของ I / O ที่พบและขนาดบล็อกที่ใช้ (ใหญ่กว่าขนาดเซกเตอร์จริงหรือไม่) ที่อยู่อินพุตและเอาต์พุตไม่ได้ซิงค์กันจริง ๆ แต่จบลงด้วยการออฟเซ็ตที่ไม่ถูกต้อง สิ่งที่ชดเชยความสำคัญ

มีหลายสถานที่แนะนำให้ใช้conv=noerror,syncเมื่อจัดการกับดิสก์ที่ไม่ดี ฉันเคยทำตามคำแนะนำตัวเอง มันใช้งานได้สำหรับฉันเมื่อฉันต้องกู้คืนดิสก์ที่ไม่ดีเมื่อไม่นานมานี้

อย่างไรก็ตามการทดสอบแสดงให้เห็นว่าสิ่งนี้ไม่น่าเชื่อถือจริง ๆ แต่อย่างใด

ใช้losetupและdmsetupเพื่อสร้างA error Bอุปกรณ์:

truncate -s 1M a.img b.img
A=$(losetup --find --show a.img)
B=$(losetup --find --show b.img)
i=0 ; while printf "A%06d\n" $i ; do i=$((i+1)) ; done > $A
i=0 ; while printf "B%06d\n" $i ; do i=$((i+1)) ; done > $B

อุปกรณ์วน A, B มีลักษณะดังนี้:

# head -n 3 $A $B
==> /dev/loop0 <==
A000000
A000001
A000002

==> /dev/loop1 <==
B000000
B000001
B000002

ดังนั้นมันคือ A, B พร้อมตัวเลขที่เพิ่มขึ้นซึ่งจะช่วยให้เราตรวจสอบการชดเชยในภายหลัง

ทีนี้เพื่อให้เกิดข้อผิดพลาดในการอ่านระหว่างอุปกรณ์ทำแผนที่สองตัวอุปกรณ์มารยาทของ Linux:

# dmsetup create AerrorB << EOF
0 2000 linear $A 0
2000 96 error
2096 2000 linear $B 48
EOF

ตัวอย่างนี้สร้างAerrorBเช่นเดียวกับใน2000ภาคส่วนของAตามด้วย2*48ภาคส่วนของข้อผิดพลาดตามมาด้วยภาคส่วนของ2000B

เพียงเพื่อยืนยัน:

# blockdev --getsz /dev/mapper/AerrorB
4096
# hexdump -C /dev/mapper/AerrorB
00000000  41 30 30 30 30 30 30 0a  41 30 30 30 30 30 31 0a  |A000000.A000001.|
00000010  41 30 30 30 30 30 32 0a  41 30 30 30 30 30 33 0a  |A000002.A000003.|
[...]
000f9fe0  41 31 32 37 39 39 36 0a  41 31 32 37 39 39 37 0a  |A127996.A127997.|
000f9ff0  41 31 32 37 39 39 38 0a  41 31 32 37 39 39 39 0a  |A127998.A127999.|
000fa000
hexdump: /dev/mapper/AerrorB: Input/output error

ดังนั้นอ่านจนกระทั่งA127999\nเนื่องจากแต่ละบรรทัดมี 8 ไบต์รวมที่ 1024000 ไบต์ซึ่งเป็นภาค 2000 ของเรา 512 ไบต์ ดูเหมือนว่าทุกอย่างจะเป็นไปตามลำดับ ...

มันจะผสมผสาน?

for bs in 1M 64K 16K 4K 512 42
do
    dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.gnu-dd
    busybox dd bs=$bs conv=noerror,sync if=/dev/mapper/AerrorB of=AerrorB.$bs.bb-dd
done

ddrescue /dev/mapper/AerrorB AerrorB.ddrescue

ผล:

# ls -l
-rw-r--r-- 1 root root 2113536 May 11 23:54 AerrorB.16K.bb-dd
-rw-r--r-- 1 root root 2064384 May 11 23:54 AerrorB.16K.gnu-dd
-rw-r--r-- 1 root root 3145728 May 11 23:54 AerrorB.1M.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.1M.gnu-dd
-rw-r--r-- 1 root root 2097186 May 11 23:54 AerrorB.42.bb-dd
-rw-r--r-- 1 root root 2048004 May 11 23:54 AerrorB.42.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.4K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.512.gnu-dd
-rw-r--r-- 1 root root 2162688 May 11 23:54 AerrorB.64K.bb-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.64K.gnu-dd
-rw-r--r-- 1 root root 2097152 May 11 23:54 AerrorB.ddrescue

จากขนาดไฟล์เพียงอย่างเดียวคุณสามารถบอกได้ว่าสิ่งผิดปกติสำหรับบางบล็อค

checksums:

# md5sum *
8972776e4bd29eb5a55aa4d1eb3b8a43  AerrorB.16K.bb-dd
4ee0b656ff9be862a7e96d37a2ebdeb0  AerrorB.16K.gnu-dd
7874ef3fe3426436f19ffa0635a53f63  AerrorB.1M.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.1M.gnu-dd
94abec9a526553c5aa063b0c917d8e8f  AerrorB.42.bb-dd
1413c824cd090cba5c33b2d7de330339  AerrorB.42.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.4K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.bb-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.512.gnu-dd
3c101af5623fe8c6f3d764631582a18e  AerrorB.64K.bb-dd
6f60e9d5ec06eb7721dbfddaaa625473  AerrorB.64K.gnu-dd
b381efd87f17354cfb121dae49e3487a  AerrorB.ddrescue

ddเห็นด้วยกับddrescueเฉพาะขนาดบล็อกที่จัดแนวกับโซนข้อผิดพลาดของเรา ( 512, 4K)

ตรวจสอบข้อมูลดิบ

# grep -a -b --only-matching B130000 *
AerrorB.16K.bb-dd:  2096768:B130000
AerrorB.16K.gnu-dd: 2047616:B130000
AerrorB.1M.bb-dd:   2113152:B130000
AerrorB.1M.gnu-dd:  2064000:B130000
AerrorB.42.bb-dd:   2088578:B130000
AerrorB.42.gnu-dd:  2039426:B130000
AerrorB.4K.bb-dd:   2088576:B130000
AerrorB.4K.gnu-dd:  2088576:B130000
AerrorB.512.bb-dd:  2088576:B130000
AerrorB.512.gnu-dd: 2088576:B130000
AerrorB.64K.bb-dd:  2113152:B130000
AerrorB.64K.gnu-dd: 2064000:B130000
AerrorB.ddrescue:   2088576:B130000

ในขณะที่ข้อมูลดูเหมือนว่าจะมีอยู่ก็ไม่ชัดเจนในการซิงค์; ออฟเซ็ตจะไม่ตีอย่างสมบูรณ์สำหรับ bs = 16K, 1M, 42,64K ... เฉพาะผู้ที่มีออฟเซ็ต2088576เท่านั้นที่ถูกต้องเนื่องจากสามารถตรวจสอบได้กับอุปกรณ์ดั้งเดิม

# dd bs=1 skip=2088576 count=8 if=/dev/mapper/AerrorB 
B130000

สิ่งนี้เป็นพฤติกรรมที่คาดหวังdd conv=noerror,syncหรือไม่? ฉันไม่รู้และการใช้งานสองอย่างของddฉันที่มีอยู่ไม่เห็นด้วยซึ่งกันและกัน ผลลัพธ์จะไร้ประโยชน์อย่างมากถ้าคุณใช้ddกับตัวเลือกบล็อกขนาดนักแสดง

ดังกล่าวข้างต้นได้รับการผลิตโดยใช้dd (coreutils) 8.25, ,BusyBox v1.24.2GNU ddrescue 1.21


3
น่าสนใจมากและมีรายละเอียด แต่ก็ยังสับสน คุณเห็นสิ่งนี้เป็นข้อผิดพลาดหรือไม่? มีการรายงานหรือไม่? หรือว่าผู้ใช้ต้องแน่ใจว่าใช้อาร์กิวเมนต์ bs = ที่สอดคล้องกับขนาดบล็อกจริงของอุปกรณ์
nealmcb

@frostschutz คุณจะแนะนำให้ใช้ddrescueแทนddเมื่อทำงานกับไดรฟ์ที่มีเซกเตอร์เสียหรือไม่
ljk

2
ไม่มี syncอาร์กิวเมนต์บอกมันเพื่อให้การส่งออกระยะเวลาที่ถูกต้อง มันไม่ทำงานถ้าคุณใช้ขนาดบล็อกที่ไม่ถูกต้องดังนั้นอย่าทำอย่างนั้น
psusi

11
เฮ้iflag=fullblockดูเหมือนว่าจะบันทึก แม้ว่าmd5sums ของรูปภาพที่ทำด้วยiflag=fullblockยังคงแตกต่างกัน (แน่นอน! เนื่องจากจำนวนไบต์ที่ถูกข้ามเนื่องจากข้อผิดพลาดในการอ่านแตกต่างกัน - นั่นคือจำนวนของ\0s ในรูปภาพต่างกัน), แต่การจัดตำแหน่งจะถูกบันทึกด้วยiflag=fullblock: grep -a -b --only-matching B130000ส่งกลับ2088576สำหรับรูปภาพทั้งหมด
Sasha

2
@Sasha ถูกต้องและต้องการ upvotes มากขึ้น! fullblockถูกกล่าวถึงในเอกสารgnu.org/software/coreutils/manual/html_node/dd-invocation.html
mlt
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.