Mengapa "/ dev / rdisk" sekitar 20 kali lebih cepat dari "/ dev / disk" di Mac OS X


129

Menurut dokumentasi pi rasbery , Anda dapat memuat OS Anda ke kartu flash dengan / dev / disk atau / dev / rdisk.

rdisk adalah singkatan dari raw disk.

/ dev / disk adalah perangkat tingkat blok, mengapa rdisk akan 20 kali lebih cepat?

Menggunakan Mac OSX

Catatan: Dalam OS X setiap disk dapat memiliki dua referensi jalur di / dev: / dev / disk # adalah perangkat buffered, yang berarti setiap data yang dikirim mengalami pemrosesan ekstra. / dev / rdisk # adalah jalur mentah, yang jauh lebih cepat, dan sangat oke ketika menggunakan program dd. Pada kartu SD Class 4 perbedaannya sekitar 20 kali lebih cepat menggunakan jalur rdisk.


3
Sebagai catatan, saya menjalankan tes dan rdisk sebenarnya membutuhkan waktu lebih lama.
Spuder

4
Sebagai catatan tambahan, saya merasa saya harus mengujinya juga, dan menemukan bahwa salinan rdisk (via dd) hampir persis 4 kali lebih cepat daripada menggunakan disk.
Travis Griggs

Mac OSX 10.9.1 (MacBook Pro 15-inch, Awal 2011)
Travis Griggs

2
Saya pikir "rdisk" adalah kesalahan ketik dalam beberapa instruksi untuk gambar kartu SD Raspberry Pi yang saya baca. Setelah diselidiki lebih lanjut, saya mencari perbedaannya di Google dan menemukan utas ini. Ternyata dalam kasus saya 13 kali lebih cepat untuk menulis gambar 1.7GB ke kartu SD menggunakan / dev / rdisk daripada / dev / disk! Macbook Pro Retina 13 ", model awal 2015
tobias.mcnulty

2
Sebagai sidenote lain, saya baru saja menggunakan gambar ARM Ubuntu untuk kartu Sandisk Extreme Pro MicroSD yang baru saya beli. / dev / disk1 menulis di 2,3 MB / s, sementara / dev / rdisk1 menulis di 83,7 MB / s, atau 36,4 kali lebih cepat.
DanielSmedegaardBuus

Jawaban:


93

Dari man hdiutil:

/ dev / rdisk node adalah perangkat khusus karakter, tetapi "mentah" dalam arti BSD dan memaksa I / O blok-blok. Mereka lebih dekat ke disk fisik daripada cache buffer. / dev / disk node, di sisi lain, adalah perangkat khusus blok buffered dan digunakan terutama oleh kode sistem file kernel.

Dalam istilah awam /dev/rdiskhampir langsung ke disk dan /dev/diskpergi melalui rute yang lebih mahal lagi


14
mengapa menggunakan disk saat Anda dapat menggunakan rdisk?
user391339

20
@ user391339 Karena caching masih merupakan hal yang diinginkan. Dalam kasus di mana Anda memiliki media yang dapat dilepas, Anda ingin mendapatkan data pada perangkat fisik secepat mungkin, karena Anda menginginkan data di lokasi fisik lain. Hard drive internal adalah cerita yang berbeda. Anda biasanya tidak membawanya, jadi Anda tidak peduli kapan data sebenarnya ditulis ke perangkat. Ketika Anda men-cache data yang ditulis / dibaca dari perangkat itu cara yang lebih mahal untuk menulis ke disk, tetapi program Anda masih lebih cepat, karena mereka tidak perlu menunggu sampai semua data yang ingin mereka tulis ditulis ke disk.
Kritzefitz

@Dan, Re "force"; berarti?
Pacerier

Tidak yakin penjelasan Krit cocok untuk saya. Kasing saya mungkin agak istimewa yang ingin melakukan pemindaian disk eksternal besar yang lebih cepat, dan saya tidak yakin metode mana yang bekerja lebih baik untuk itu, tetapi sebaliknya saya masih baik-baik saja dengan penggunaan normal dan menunggu untuk mengeluarkan seperti biasa praktek. Namun di Windows saya selalu lebih suka profil 'cabut cepat' yang saya kira mencerminkan mode Mac lebih 'baku' karena mengiklankan lebih sedikit korupsi sistem file dalam peristiwa kehilangan koneksi yang tidak terduga.
Pysis

96

Jawaban yang diterima benar, tetapi tidak terlalu rinci.

Salah satu perbedaan utama antara /dev/diskdan /dev/rdisk, ketika Anda mengaksesnya dari ruang pengguna, adalah yang /dev/diskdisangga. Jalur baca / tulis untuk /dev/diskmemecah I / O menjadi potongan 4KB, yang terbaca ke dalam cache buffer, dan kemudian menyalin ke buffer ruang pengguna (dan kemudian mengeluarkan 4KB baca selanjutnya ...). Ini bagus karena Anda dapat melakukan baca dan tulis yang tidak selaras, dan hanya berfungsi. Sebaliknya, /dev/rdiskpada dasarnya hanya meneruskan membaca atau menulis langsung ke perangkat, yang berarti awal dan akhir I / O perlu disejajarkan pada batas-batas sektor.

Jika Anda membaca atau menulis lebih dari satu sektor /dev/rdisk, permintaan itu akan diteruskan. Lapisan bawah dapat memecahnya (mis., USB memecahnya menjadi potongan-potongan 128KB karena ukuran muatan maksimum dalam protokol USB), tetapi Anda biasanya bisa mendapatkan I / Os yang lebih besar dan lebih efisien. Saat streaming, seperti via dd, 128KB ke 1MB adalah ukuran yang cukup bagus untuk mendapatkan kinerja mendekati optimal pada perangkat keras non-RAID saat ini.

Caching yang dilakukan oleh /dev/diskjalur baca dan tulis sangat sederhana dan hampir mati otak. Tembolok bahkan jika tidak benar-benar diperlukan; seperti jika perangkat dapat memetakan memori dan langsung mentransfer ke buffer aplikasi Anda. Itu kecil (4KB) I / Os, yang mengarah ke banyak overhead per-I / O. Itu tidak membaca atau menulis di belakang.


6

Tampaknya /dev/diskdan /dev/rdiskberfungsi berbeda untuk HDD dan SSD. Ingin memeriksanya untuk kartu MicroSD. Baru saja menulis gambar disk 2GB ke Sandisk Ultra MicroSD 64GB ( https://www.amazon.com/gp/product/B073JYVKNX ).

Tes berulang beberapa kali, tetapi hasilnya stabil: 17MB / s untuk /dev/diskvs 20MB / s untuk /dev/rdisk. Mengubah bs=1mmenjadi bs=16msama sekali tidak ada perbedaan dalam kecepatan menulis.

  1. Menulis untuk /dev/disk2

    sudo dd if=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531.img of=/dev/disk2 bs=1m
    2094006272 bytes transferred in 121.860007 secs (17183704 bytes/sec)
    
  2. Menulis untuk /dev/rdisk2

    $ sudo dd if=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531.img of=/dev/rdisk2 bs=1m
    2094006272 bytes transferred in 102.743870 secs (20380839 bytes/sec)
    

Kemudian saya memutuskan untuk menguji kecepatan membaca: 26MB / s untuk /dev/diskvs 87MB / s untuk /dev/rdisk. Mengubah bs=1mmenjadi bs=16msama sekali tidak ada perbedaan dalam kecepatan membaca.

  1. Membaca dari /dev/disk2

    sudo dd if=/dev/disk2 of=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531-2.img bs=1m
    257949696 bytes transferred in 9.895572 secs (26067184 bytes/sec)
    
  2. Membaca dari /dev/rdisk2

    $ sudo dd if=/dev/rdisk2 of=~/Downloads/ubuntu-18.04-4.14-minimal-odroid-xu4-20180531.img bs=1m
    877658112 bytes transferred in 10.021974 secs (87573377 bytes/sec)
    

2

Saya tahu ini adalah utas lama, tetapi orang lain mungkin tertarik pada implikasi kecepatan dari apa yang saya coba. Saya ingin mencadangkan SSD internal saya di Retina MacBook Pro 13 "saya (dengan Silicon Power 1 TB SSD) ke hard disk USB 3.0 2.5" eksternal, yang ingin menangkap partisi macOS dan BOOTCAMP. Baris perintah awal saya adalah:

sudo dd if=/dev/disk0 of=/dev/disk2 bs=1m

Hasilnya adalah tingkat salinan ~ 31,3 MB / detik. Ini terlalu lama untuk membuatku menunggu. Jadi, pada upaya kedua, baris perintah adalah:

sudo dd if=/dev/rdisk0 of=/dev/rdisk2 bs=1m

Menggunakan /dev/rdiskalih-alih /dev/diskmempercepat secara signifikan, sekitar 98,4 MB / detik! Namun, itu menjadi lebih baik. Jadi, untuk upaya ketiga, saya menggunakan baris perintah ini:

sudo dd if=/dev/rdisk0 of=/dev/rdisk2 bs=1m conv=sparse

Opsi jarang memberi tahu DD untuk tidak repot menulis ke blok keluaran yang semuanya 0s pada input. Apa yang keren adalah bahwa ini menjadi jauh lebih cepat daripada yang Anda pikirkan, bahkan ketika di tengah-tengah "penuh" area disk. Pada setiap drive yang tidak penuh, Anda akan memiliki potongan besar 0s, lebih lanjut mempercepat DD. Sejauh ini, setidaknya, DD hanya berjalan dengan kecepatan transfer teoritis hard disk saya: ~ 116,4 MB / detik, dan belum mencapai area kosong yang besar itu.

Cobalah opsi ini - mereka berhasil! Harap perhatikan: DENGAN SEKSAMA ubah if=dan  of=untuk menunjuk dengan benar ke drive yang benar yang terdaftar oleh (untuk Mac):

diskutil list

1
conv=sparsesangat bagus saat Anda menyalin file.    Saya akan khawatir bahwa itu mungkin memperkenalkan korupsi ketika menyalin seluruh disk, partisi atau sebuah  filesystem , kecuali Anda tahu dengan kepastian 100% bahwa disk tujuan berisi apa-apa tapi nol.
G-Man

1

Sebagai catatan, setidaknya di macOS High Sierra, / dev / disk tampaknya jauh lebih cepat daripada / dev / rdisk. Menjalankan dd atau ddrescue, perbandingan throughput saya menyalin dari HD magnetik ke SSD adalah 3,7MBps menggunakan / dev / rdisk, dan 45MBps menggunakan / dev / disk. Jadi, pada versi macOS yang lebih baru, mungkin lebih baik menggunakan / dev / disk daripada / dev / rdisk untuk kinerja terbaik.


2
Saat menulis gambar raspbian-stretch 4,6GB dari penyimpanan SSD internal ke kartu SD dengan dd dan bs 1MB / dev / rdisk masih melakukan jauh lebih cepat daripada / dev / disk pada akhir 2013 macbook pro menjalankan macOS 10.13.2. Butuh 27,16 menit menggunakan / dev / disk dan hanya 5,18 menit menggunakan / dev / rdisk.
digitaladdictions

@digitaladdictions baru saja melakukan beberapa tes pada MacOS terbaru: superuser.com/a/1346063/126537
k06a

0

Saya pikir sebelum berdebat jalur mana node lebih cepat atau menyelam ke dalam tes serial. Kita harus mempertimbangkan faktor lain yang secara dramatis akan mempengaruhi kecepatan baca / tulis akhir.

seperti spesifikasi kartu Micro SD, kelas 4/10 / HC I ... sd card reader chip dan interface, usb 1.1 / 2.0 / 3.0 / 3.1 os total memori / memori bebas, os load, os jenis harddisk, HDD / SSD, HDD kecepatan putaran dan ukuran cache, ukuran SSD / cache / ruang bebas / antarmuka harddisk os, ata / sata / esata,

jika ada faktor yang menjadi hambatan, maka kita akan mendapatkan kesimpulan yang salah.

inilah hasil saya: osx 10.12.6, ssd,

membaca microSD 16G dengan kartu usb 2.0 membaca dan menulis ke HDD 3,5 inci eksternal dengan usb 3.0,

15193+1 records in
15193+1 records out
15931539456 bytes transferred in 1423.067033 secs (11195214 bytes/sec)

tulis microSD 32G melalui pembacaan kartu internal dan sumber data adalah HDD 3,5 inci eksternal dengan usb 3.0,

0+253945 records in
0+253945 records out
15931539456 bytes transferred in 440.093686 secs (36200336 bytes/sec)

Anda dapat melihat, menulis kecepatan> kecepatan baca !!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.