มีวิธีในการกำหนดค่าที่เหมาะสมที่สุดสำหรับพารามิเตอร์ bs เป็น dd หรือไม่?

ในบางครั้งฉันเห็นความคิดเห็นออนไลน์ตามบรรทัดของ "ให้แน่ใจว่าคุณตั้งค่า 'bs =' เพราะค่าเริ่มต้นจะใช้เวลานานเกินไป" และประสบการณ์ที่ไม่มีหลักวิทยาศาสตร์ของฉันเอง "ซึ่งดูเหมือนจะใช้เวลานานกว่าที่อื่น เวลาเมื่อสัปดาห์ที่แล้ว "ดูเหมือนจะทนได้ ดังนั้นเมื่อใดก็ตามที่ฉันใช้ 'dd' (โดยทั่วไปจะอยู่ในช่วง 1-2GB) ฉันแน่ใจว่าได้ระบุพารามิเตอร์ bytes ประมาณครึ่งหนึ่งที่ฉันใช้ค่าที่ระบุในคู่มือออนไลน์ที่ฉันกำลังคัดลอกมา เวลาที่เหลือฉันจะเลือกหมายเลขที่เหมาะสมจากรายการ 'fdisk -l' สำหรับสิ่งที่ฉันถือว่าเป็นสื่อที่ช้ากว่า (เช่นการ์ด SD ที่ฉันเขียน)

สำหรับสถานการณ์ที่กำหนด (ประเภทสื่อขนาดบัสหรืออะไรก็ตามที่สำคัญ) มีวิธีการกำหนดค่า "ดีที่สุด" หรือไม่? มันง่ายที่จะกำหนด? ถ้าไม่มีวิธีง่ายๆในการรับ 90-95% จากที่นั่นหรือไม่? หรือ "เพียงแค่เลือกสิ่งที่ใหญ่กว่า 512" แม้แต่คำตอบที่ถูกต้องหรือไม่

ฉันคิดว่าจะลองทำการทดสอบด้วยตัวเอง แต่ (นอกเหนือจากการทำงานมาก ๆ ) ฉันไม่แน่ใจว่าปัจจัยใดที่ส่งผลกระทบต่อคำตอบดังนั้นฉันจึงไม่รู้วิธีออกแบบการทดสอบที่ดี

ddวันที่ย้อนหลังเมื่อจำเป็นต้องแปลเทปเมนเฟรมของ IBM เก่าและขนาดบล็อกต้องตรงกับขนาดที่ใช้ในการเขียนเทปหรือบล็อคข้อมูลจะถูกข้ามหรือตัดทอน (เทป 9 แทร็กมีความพิถีพิถันดีใจที่พวกเขาตายไปนานแล้ว) วันนี้ขนาดบล็อกควรเป็นขนาดเซกเตอร์ของอุปกรณ์หลายอัน (ปกติคือ 4KB แต่ในดิสก์ล่าสุดอาจมีขนาดใหญ่กว่าและใช้นิ้วโป้งขนาดเล็กมาก ไดรฟ์อาจมีขนาดเล็กลง แต่ 4KB เป็นพื้นกลางที่เหมาะสมโดยไม่คำนึงถึง) และยิ่งมีประสิทธิภาพที่ดีกว่า ฉันมักจะใช้ขนาดบล็อก 1MB กับฮาร์ดไดรฟ์ (เรามีหน่วยความจำมากขึ้นในการโยนรอบวันเหล่านี้ด้วย)

มีเพียงวิธีหนึ่งในการกำหนดขนาดบล็อกที่เหมาะสมและนั่นคือมาตรฐาน ฉันเพิ่งทำเกณฑ์มาตรฐานอย่างรวดเร็ว เครื่องทดสอบคือพีซีที่ใช้ Debian GNU / Linux พร้อมเคอร์เนล 2.6.32 และ coreutils 8.5 ระบบไฟล์ทั้งสองนี้มีส่วนเกี่ยวข้องกับ ext3 บนวอลุ่ม LVM บนพาร์ติชันฮาร์ดดิสก์ ไฟล์ต้นฉบับคือ 2GB (เพื่อให้แม่นยำ 2040000kB) เปิดใช้งานการแคชและการบัฟเฟอร์ sync; echo 1 >|/proc/sys/vm/drop_cachesก่อนที่จะทำงานแต่ละผมยอบแคชกับ เวลารันไม่มีการกำหนดขั้นสุดท้ายsyncเพื่อล้างบัฟเฟอร์ รอบสุดท้ายsyncใช้เวลาในการสั่งซื้อ 1 วินาที การsameทำงานถูกคัดลอกบนระบบไฟล์เดียวกัน การdiffทำงานถูกคัดลอกไปยังระบบไฟล์บนฮาร์ดดิสก์อื่น เพื่อความสอดคล้องกันเวลาที่รายงานคือเวลานาฬิกาแขวนที่ได้รับด้วยtimeยูทิลิตี้ในไม่กี่วินาที ฉันรันแต่ละคำสั่งเพียงครั้งเดียวดังนั้นฉันจึงไม่ทราบว่ามีความแปรปรวนเท่าใดในช่วงเวลานั้น

             same   diff
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

สรุป: ขนาดบล็อกขนาดใหญ่ (หลายเมกะไบต์) ช่วยได้ แต่ไม่มาก (น้อยกว่าที่ฉันคาดไว้สำหรับการคัดลอกไดรฟ์เดียวกัน) และcatและcpไม่ได้ทำอย่างเลวร้าย ด้วยตัวเลขเหล่านี้ฉันไม่คิดว่าจะddคุ้มค่ากับการรบกวน ไปกับcat!

ฉันเห็นด้วยกับ geekosaur ว่าขนาดควรเป็นหลายเท่าของขนาดบล็อกซึ่งมักจะเป็น 4K

หากคุณต้องการค้นหาขนาดบล็อกstat -c "%o" filenameน่าจะเป็นตัวเลือกที่ง่ายที่สุด

แต่บอกว่าคุณทำdd bs=4Kนั่นหมายความว่ามันจะread(4096); write(4096); read(4096); write(4096)...

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

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

โดยตรรกะbs=16Kนั้นดียิ่งขึ้น ฯลฯ

ดังนั้นสิ่งที่ฉันอยากรู้คือถ้ามีขีด จำกัด สูงสุดที่ประสิทธิภาพการทำงานเริ่มแย่ลงหรือถ้ามันถูก จำกัด ด้วยหน่วยความจำเท่านั้น

ดังที่ Gilles บอกไว้คุณสามารถกำหนดพารามิเตอร์ที่เหมาะสมที่สุดสำหรับตัวเลือกbsเป็นddโดยการเปรียบเทียบ อย่างไรก็ตามสิ่งนี้ขอให้คำถาม: คุณจะวัดพารามิเตอร์นี้ได้อย่างสะดวกได้อย่างไร

คำตอบเบื้องต้นของฉันสำหรับคำถามนี้คือ: ใช้dd-opt , ยูทิลิตี้ที่ฉันเพิ่งเริ่มทำงานเพื่อแก้ไขปัญหานี้อย่างแม่นยำ :)

ผมที่เหมาะสำหรับผู้อ่าน USB2.0 sdcard bs=10Mซึ่งดูเหมือนว่าจะทำงานที่ดีที่สุดใน ฉันลอง 4k ขึ้นไป 16M หลังจาก 8-10M ไม่มีการปรับปรุง คุณสามารถดูวิธีการวัดอัตราการถ่ายโอนที่ลดลง ... น่าจะเกิดจากการโหลดบัฟเฟอร์บนอุปกรณ์จากนั้นรอให้อุปกรณ์ถ่ายโอนไปยังสื่อจริง

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s