Apakah opsi "bs" di "dd" benar-benar meningkatkan kecepatan?

58

Sesekali, saya diberitahu bahwa untuk meningkatkan kecepatan "dd" saya harus hati-hati memilih "ukuran blok" yang tepat.

Bahkan di sini, di ServerFault, orang lain menulis bahwa " ... ukuran blok optimal tergantung pada perangkat keras ... " (iain) atau " ... ukuran sempurna akan tergantung pada bus sistem Anda, pengontrol hard drive, drive tertentu sendiri, dan driver untuk masing-masing ... " (chris-s)

Karena perasaan saya sedikit berbeda ( BTW: Saya berpendapat bahwa waktu yang dibutuhkan untuk menyempurnakan parameter bs jauh lebih tinggi daripada perolehan yang diterima, dalam hal menghemat waktu, dan bahwa standarnya masuk akal ), hari ini saya hanya pergi melalui beberapa tolok ukur cepat dan kotor.

Untuk menurunkan pengaruh eksternal, saya memutuskan untuk membaca:

  • dari kartu MMC eksternal
  • dari partisi internal

dan:

  • dengan filesystem terkait umounted
  • mengirimkan output ke / dev / null untuk menghindari masalah yang terkait dengan "kecepatan menulis";
  • menghindari beberapa masalah dasar caching HDD, setidaknya ketika melibatkan HDD.

Dalam tabel berikut, saya telah melaporkan temuan saya, membaca 1GB data dengan nilai "bs" yang berbeda ( Anda dapat menemukan angka mentah di akhir pesan ini ):

masukkan deskripsi gambar di sini

Pada dasarnya disebutkan bahwa:

  • MMC: dengan bs = 4 (ya! 4 byte), saya mencapai throughput 12MB / s. Nilai yang tidak terlalu jauh mencapai maksimum 14.2 / 14.3 yang saya dapatkan dari bs = 5 ke atas;

  • HDD: dengan bs = 10 saya mencapai 30 MB / s. Tentunya lebih rendah dari 95,3 MB yang didapat dengan default bs = 512 tetapi ... signifikan juga.

Juga, sangat jelas bahwa waktu sys CPU berbanding terbalik dengan nilai bs (tapi ini terdengar masuk akal, karena semakin rendah bs, semakin tinggi jumlah panggilan sys yang dihasilkan oleh dd).

Setelah mengatakan semua hal di atas, sekarang pertanyaannya: dapatkah seseorang menjelaskan (peretas kernel?) Apa saja komponen / sistem utama yang terlibat dalam throughput seperti itu, dan jika benar-benar sepadan dengan usaha dalam menetapkan bs lebih tinggi dari standar?

Kasing MMC - angka mentah

bs = 1 jt

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1M count=1000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 74,1239 s, 14,1 MB/s

real    1m14.126s
user    0m0.008s
sys     0m1.588s

bs = 1k

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1k count=1000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,7795 s, 14,1 MB/s

real    1m12.782s
user    0m0.244s
sys     0m2.092s

bs = 512

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=512 count=2000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,867 s, 14,1 MB/s

real    1m12.869s
user    0m0.324s
sys     0m2.620s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,1662 s, 14,3 MB/s

real    1m10.169s
user    0m6.272s
sys     0m28.712s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,415 s, 14,2 MB/s

real    1m10.417s
user    0m11.604s
sys     0m55.984s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 80,9114 s, 12,4 MB/s

real    1m20.914s
user    0m14.436s
sys     1m6.236s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 161,974 s, 6,2 MB/s

real    2m41.976s
user    0m28.220s
sys     2m13.292s

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 325,316 s, 3,1 MB/s

real    5m25.318s
user    0m56.212s
sys     4m28.176s

Kasing HDD - angka mentah

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 341,461 s, 2,9 MB/s

real    5m41.463s
user    0m56.000s
sys 4m44.340s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 164,072 s, 6,1 MB/s

real    2m44.074s
user    0m28.584s
sys 2m14.628s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 81,471 s, 12,3 MB/s

real    1m21.473s
user    0m14.824s
sys 1m6.416s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 66,0327 s, 15,1 MB/s

real    1m6.035s
user    0m11.176s
sys 0m54.668s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 33,4151 s, 29,9 MB/s

real    0m33.417s
user    0m5.692s
sys 0m27.624s

bs = 512 (mengimbangi baca, untuk menghindari caching)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=512 count=2000000 skip=6000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,7437 s, 95,3 MB/s

real    0m10.746s
user    0m0.360s
sys 0m2.428s

bs = 1k (mengimbangi membaca, untuk menghindari caching)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1k count=1000000 skip=6000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,6561 s, 96,1 MB/s

real    0m10.658s
user    0m0.164s
sys 0m1.772s

bs = 1k (mengimbangi membaca, untuk menghindari caching)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1M count=1000 skip=7000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 10,7391 s, 97,6 MB/s

real    0m10.792s
user    0m0.008s
sys 0m1.144s
linux kernel dd disk-image Damiano Verzulli
sumber
11
Apa yang akan sangat menyenangkan adalah memiliki bs=autofitur ddyang akan mendeteksi dan menggunakan parameter bs optimal dari perangkat.
4
Apa yang akan sangat bagus adalah grafik dengan beberapa bsukuran yang diplot dengan kecepatan alih-alih 15 lusin blok kode dalam satu pertanyaan. Akan mengambil sedikit ruang dan menjadi jauh lebih cepat untuk membaca. Sebuah gambar benar - benar bernilai sebuah kata-kata kasar.
MDMoore313
2
@BigHomie - Saya kira memberikan grafik tapi ... ada beberapa masalah "scaling". Mungkin perlu, mungkin, skala logaritmik pada kedua sumbu dan ... sambil berpikir untuk ini, saya kira itu bukan masalah yang mudah (dan cepat) untuk dipecahkan. Jadi saya beralih ke versi "tabel". Adapun "... 15 lusin blok kode", saya ingin semua orang memiliki kesempatan untuk memeriksa "angka mentah", untuk menghindari gangguan (pribadi, milik saya).
Damiano Verzulli
1
@ DamianoVerzulli mejanya keren, tolong abaikan kata-kata kasar saya, saya memberi Anda upvote untuk membuktikan takhayul kami, dan saya tahu secara langsung bahwa mengutak-atik ukuran byte akan mengubah kecepatan, saya mungkin memasukkannya ke dalam jawaban juga.
MDMoore313
1
@warren - untuk mendapatkan 4G Anda juga dapat melakukannya bs=8k count=512Katau bs=1M count=4Ksaya tidak ingat kekuatan 2 65536 terakhir
user313114

Jawaban:

24

Apa yang Anda lakukan hanyalah tes kecepatan baca. jika Anda benar-benar menyalin blok ke perangkat lain, Anda memiliki jeda dalam pembacaan saat perangkat lain menerima data yang ingin Anda tulis, ketika ini terjadi, Anda dapat menekan masalah latensi rotasi pada perangkat baca (jika itu hard disk) dan sebagainya sering kali secara signifikan lebih cepat untuk membaca potongan 1M dari HDD saat Anda menghadapi latensi rotasi lebih jarang.

Saya tahu ketika saya menyalin hard disk saya mendapatkan tingkat yang lebih cepat dengan menentukan bs=1Mdaripada menggunakan bs=4katau default. Saya berbicara peningkatan kecepatan 30 hingga 300 persen. Tidak perlu mencari yang terbaik kecuali jika itu yang Anda lakukan setiap hari. tetapi memilih sesuatu yang lebih baik daripada standar dapat memotong jam waktu eksekusi.

Ketika Anda menggunakannya secara nyata coba beberapa nomor berbeda dan kirim sinyal ddproses SIGUSR1untuk membuatnya mengeluarkan laporan status sehingga Anda dapat melihat bagaimana hasilnya.

✗ killall -SIGUSR1 dd
1811+1 records in
1811+1 records out
1899528192 bytes (1.9 GB, 1.8 GiB) copied, 468.633 s, 4.1 MB/s
pengguna313114
sumber
2014 Macbook Pro Retina menyalin ke tongkat USB3 dengan nilai 90 MB / s tulis: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 status=progressmenunjukkan 6140928 bytes (6.1 MB, 5.9 MiB) copied, 23 s, 267 kB/s. Saya membatalkan ini karena terlalu lama. Sekarang tentukan bytesize: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 bs=1M status=progressshows4558159872 bytes (4.6 GB, 4.2 GiB) copied, 54 s, 84.4 MB/s
Eric Duncan
9

Sehubungan dengan hard disk internal, setidaknya - ketika Anda membaca dari perangkat lapisan blok setidaknya harus mengambil satu sektor yang 512 byte.

Jadi, ketika menangani pembacaan 1 byte, Anda hanya benar-benar membaca dari disk pada sektor pencarian byte yang diluruskan. Sisa 511 kali dilayani oleh cache.

Anda dapat membuktikan ini sebagai berikut, dalam contoh ini sdbadalah disk yang menarik:

# grep sdb /proc/diskstats
8      16 sdb 767 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...
# dd if=/dev/sdb of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.0371715 s, 13.8 kB/s
# grep sedb /proc/diskstats
8      16 sdb 768 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...

Kolom keempat (yang menghitung dibaca) menunjukkan hanya 1 baca terjadi, meskipun Anda meminta 1 byte dibaca. Ini adalah perilaku yang diharapkan karena perangkat ini (disk SATA 2) minimal harus mengembalikan ukuran sektornya. Kernel hanya melakukan caching seluruh sektor.

Faktor terbesar yang berperan dalam permintaan ukuran ini adalah overhead dari mengeluarkan panggilan sistem untuk membaca atau menulis. Bahkan, mengeluarkan panggilan untuk <512 tidak efisien. Pembacaan sangat besar membutuhkan lebih sedikit panggilan sistem dengan biaya lebih banyak memori yang digunakan untuk melakukannya.

4096 biasanya merupakan angka 'aman' untuk dibaca karena:

  • Saat membaca dengan caching aktif (default) sebuah halaman adalah 4k. Mengisi halaman dengan <4k bacaan lebih rumit daripada menjaga agar bacaan dan ukuran halaman tetap sama.
  • Sebagian besar ukuran blok sistem file diatur ke 4k.
  • Ini bukan jumlah yang cukup kecil (mungkin untuk SSD sekarang meskipun) untuk menyebabkan overhead syscall tetapi bukan jumlah yang cukup besar untuk mengkonsumsi banyak memori.
Matthew Ife
sumber