Apakah ada cara untuk menentukan nilai optimal untuk parameter bs ke dd?

Kadang-kadang saya melihat komentar online di sepanjang baris "pastikan Anda menetapkan 'bs =' karena nilai default akan terlalu lama," dan pengalaman saya sendiri yang sangat tidak ilmiah, "nampaknya butuh waktu lebih lama daripada yang lain waktu minggu lalu "tampaknya mendukung hal itu. Jadi setiap kali saya menggunakan 'dd' (biasanya dalam kisaran 1-2GB) saya pastikan untuk menentukan parameter byte. Sekitar separuh waktu saya menggunakan nilai yang ditentukan dalam panduan online apa pun yang saya salin; sisa waktu saya akan memilih beberapa nomor yang masuk akal dari daftar 'fdisk-l' untuk apa yang saya asumsikan adalah media yang lebih lambat (misalnya kartu SD yang saya tulis).

Untuk situasi tertentu (jenis media, ukuran bus, atau apa pun yang penting), apakah ada cara untuk menentukan nilai "terbaik"? Apakah mudah ditentukan? Jika tidak, adakah cara mudah untuk mendapatkan 90-95% dari perjalanan ke sana? Atau "hanya memilih sesuatu yang lebih besar dari 512" bahkan jawaban yang benar?

Saya sudah berpikir untuk mencoba eksperimen sendiri, tetapi (selain menjadi banyak pekerjaan) saya tidak yakin faktor apa yang mempengaruhi jawaban, jadi saya tidak tahu bagaimana merancang eksperimen yang baik.

ddtanggal dari belakang ketika diperlukan untuk menerjemahkan kaset mainframe IBM lama, dan ukuran blok harus cocok dengan yang digunakan untuk menulis kaset atau blok data akan dilewati atau dipotong. (Kaset 9-track sangat rewel. Senang mereka sudah lama mati.) Belakangan ini, ukuran blok haruslah kelipatan dari ukuran sektor perangkat (biasanya 4KB, tetapi pada disk yang sangat baru mungkin jauh lebih besar dan dengan ibu jari yang sangat kecil) drive mungkin lebih kecil, tetapi 4KB adalah jalan tengah yang wajar terlepas) dan semakin besar semakin baik untuk kinerja. Saya sering menggunakan ukuran blok 1MB dengan hard drive. (Kami memiliki lebih banyak memori untuk dilemparkan hari ini juga.)

Hanya ada satu cara untuk menentukan ukuran blok optimal, dan itu tolok ukur. Saya baru saja membuat patokan cepat. Mesin uji adalah PC yang menjalankan Debian GNU / Linux, dengan kernel 2.6.32 dan coreutils 8.5. Kedua filesystem yang terlibat adalah ext3 pada volume LVM pada partisi hard disk. File sumber adalah 2GB (tepatnya 2040000kB). Caching dan buffering diaktifkan. Sebelum menjalankan, saya mengosongkan cache sync; echo 1 >|/proc/sys/vm/drop_caches. Waktu lari tidak termasuk final syncuntuk menyiram buffer; final syncmengambil urutan 1 detik. Proses sameadalah salinan pada sistem file yang sama; yang diffberjalan adalah salinan ke sistem file pada hard disk yang berbeda. Untuk konsistensi, waktu yang dilaporkan adalah jam dinding yang diperoleh dengantimeutilitas, dalam hitungan detik. Saya hanya menjalankan setiap perintah sekali, jadi saya tidak tahu berapa banyak perbedaan dalam pengaturan waktu.

             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

Kesimpulan: ukuran blok besar (beberapa megabyte) membantu, tetapi tidak secara dramatis (jauh lebih sedikit daripada yang saya harapkan untuk salinan drive yang sama). Dan catdan cpjangan berkinerja buruk. Dengan angka-angka ini, saya merasa tidak ddlayak untuk diganggu. Pergi dengan cat!

Saya setuju dengan geekosaurus bahwa ukurannya harus kelipatan dari ukuran blok, yang seringkali 4K.

Jika Anda ingin menemukan ukuran blok stat -c "%o" filenamemungkin merupakan opsi termudah.

Tapi katakanlah dd bs=4K, itu berarti read(4096); write(4096); read(4096); write(4096)...

Setiap panggilan sistem melibatkan saklar konteks, yang melibatkan beberapa overhead, dan tergantung pada penjadwal I / O, membaca dengan tulisan diselingi dapat menyebabkan disk melakukan banyak pencarian. (Mungkin bukan masalah besar dengan scheduler Linux, tapi tetap saja sesuatu untuk dipikirkan.)

Jadi jika Anda melakukannya bs=8K, Anda mengizinkan disk untuk membaca dua blok sekaligus, yang mungkin berdekatan pada disk, sebelum mencari tempat lain untuk melakukan penulisan (atau untuk melayani I / O untuk proses lain).

Dengan logika itu, bs=16Kbahkan lebih baik, dll.

Jadi yang ingin saya ketahui adalah apakah ada batas atas di mana kinerja mulai memburuk, atau jika hanya dibatasi oleh memori.

Seperti yang dikatakan Gilles, Anda dapat menentukan parameter optimal untuk opsi bs menjadi dd dengan pembandingan. Ini, bagaimanapun, menimbulkan pertanyaan: bagaimana Anda bisa dengan mudah membandingkan parameter ini?

Jawaban sementara saya untuk pertanyaan ini adalah: gunakan dd-opt , utilitas yang baru saja saya mulai kerjakan untuk memecahkan masalah ini :)

Saya dioptimalkan untuk usb2.0 sdcard reader yang tampaknya berjalan paling baik bs=10M. Saya mencoba 4k, hingga 16 juta, setelah 8-10 juta tidak ada perbaikan. Anda dapat melihat bagaimana pengukuran kecepatan transfer menurun ... kemungkinan besar karena memuat buffer pada perangkat kemudian menunggu perangkat untuk mentransfer ke media yang sebenarnya.

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