it-swarm-id.com

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

Kadang-kadang saya telah melihat komentar online di sepanjang baris "pastikan Anda menetapkan 'bs =' karena nilai default akan terlalu lama," dan pengalaman saya yang sangat tidak ilmiah dari, "baik yang sepertinya 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 (mis. 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.

74
user4443

dd tanggal 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.)

29
geekosaur

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 dengan sync; echo 1 >|/proc/sys/vm/drop_caches. Waktu menjalankan tidak termasuk sync akhir untuk membilas buffer; akhir sync mengambil urutan 1 detik.

Proses same adalah salinan pada sistem file yang sama; menjalankan diff adalah salinan ke sistem file pada hard disk yang berbeda. Untuk konsistensi, waktu yang dilaporkan adalah waktu jam dinding yang diperoleh dengan utilitas time, dalam detik. Saya hanya menjalankan setiap perintah sekali, jadi saya tidak tahu berapa banyak perbedaan dalam pengaturan waktu.

             same   diff
             t (s)  t (s)
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 cat dan cp tidak berkinerja buruk. Dengan angka-angka ini, saya tidak menemukan dd layak untuk diganggu. Pergilah 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" filename Mungkin merupakan opsi termudah.

Tetapi katakan Anda melakukannya dd bs=4K, Itu artinya 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 layanan I/O untuk proses lain ).

Dengan logika itu, bs=16K Bahkan lebih baik, dll.

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

8
Mikel

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

Jawaban sementara saya untuk pertanyaan ini adalah: use dd-opt , utilitas yang baru-baru ini saya mulai kerjakan untuk menyelesaikan masalah ini dengan tepat :)

5
sampablokuper

Saya dioptimalkan untuk usb2.0 sdcard reader yang tampaknya berjalan paling baik di 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
0
wwright