Perché "/ dev / rdisk" è circa 20 volte più veloce di "/ dev / disk" in Mac OS X.

129

Secondo la documentazione di rasbery pi , è possibile caricare il sistema operativo su una scheda flash con / dev / disk o / dev / rdisk.

rdisk sta per disco grezzo.

/ dev / disk è un dispositivo a livello di blocco, perché rdisk dovrebbe essere 20 volte più veloce?

Utilizzando Mac OSX

Nota: in OS X ogni disco può avere due riferimenti di percorso in / dev: / dev / disk # è un dispositivo con buffer, il che significa che tutti i dati inviati vengono sottoposti a ulteriore elaborazione. / dev / rdisk # è un percorso non elaborato, che è molto più veloce e perfettamente OK quando si utilizza il programma dd. Su una scheda SD di classe 4 la differenza era circa 20 volte più veloce usando il percorso rdisk.

sd-card dd disk-utility dev

— spuder
fonte

3

Come nota a margine, ho eseguito un test e rdisk in realtà ha impiegato molto più tempo.

— spuder

4

Come nota a margine, ho sentito di dover provare anche allora, e ho scoperto che una copia di rdisk (via dd) era quasi esattamente 4 volte più veloce rispetto all'uso della controparte del disco.

— Travis Griggs,

Mac OSX 10.9.1 (MacBook Pro 15 pollici, inizio 2011)

— Travis Griggs

2

Pensavo che "rdisk" fosse un refuso in alcune istruzioni per un'immagine della scheda SD Raspberry Pi che stavo leggendo. Dopo ulteriori indagini ho cercato su Google la differenza e ho trovato questa discussione. Nel mio caso è risultato che era 13 volte più veloce scrivere un'immagine da 1,7 GB su una scheda SD usando / dev / rdisk invece di / dev / disk! Macbook Pro Retina 13 ", modello inizio 2015.

— tobias.mcnulty

2

Come ennesimo sidenote, ho appena creato un'immagine ARM di Ubuntu sulla mia scheda MicroSD Sandisk Extreme Pro appena acquistata. / dev / disk1 ha scritto a 2,3 MB / s, mentre / dev / rdisk1 ha scritto a 83,7 MB / s, o 36,4 volte più veloce.

— DanielSmedegaardBuus

93

Da man hdiutil:

I nodi / dev / rdisk sono dispositivi speciali per i caratteri, ma sono "grezzi" nel senso BSD e forza l'I / O allineato a blocchi. Sono più vicini al disco fisico rispetto alla cache del buffer. I nodi / dev / disk, d'altra parte, sono dispositivi speciali a blocchi bufferizzati e sono usati principalmente dal codice del filesystem del kernel.

In parole povere /dev/rdiskva quasi direttamente sul disco e /dev/diskpassa attraverso un percorso più lungo e più costoso

— Daniël W. Crompton
fonte

14

perché usare il disco quando puoi usare rdisk?

— user391339

20

@ user391339 Perché la memorizzazione nella cache è ancora una cosa desiderabile. Nei casi in cui si dispone di supporti rimovibili, si desidera ottenere i dati sul dispositivo fisico il più rapidamente possibile, perché si desidera i dati in un'altra posizione fisica. I dischi rigidi interni sono una storia diversa. Di solito non li porti in giro, quindi non ti importa quando i dati vengono effettivamente scritti sul dispositivo. Quando si memorizzano nella cache i dati scritti / letti dai dispositivi, questo è un modo più costoso di scrivere sul disco, ma i programmi sono ancora più veloci, poiché non è necessario attendere che tutti i dati che desiderano scrivere vengano scritti sul disco.

— Kritzefitz,

@Dan, Re "force"; senso?

— Pacerier

Non sono sicuro che la spiegazione di Krit funzioni per me. Il mio caso potrebbe essere un po 'speciale nel voler eseguire una scansione una tantum di dischi esterni più grandi e più veloci, e non sono sicuro di quale metodo funzioni meglio per quello, ma per il resto sto ancora bene con l'uso normale e aspetto che venga espulso come è comune pratica. In Windows, tuttavia, ho sempre preferito il profilo di "disinserimento rapido" che immagino rispecchi la modalità più "grezza" di Mac perché pubblicizza meno corruzione del filesystem in eventi imprevisti di perdita della connessione.

— Pysis,

96

La risposta accettata è giusta, ma non è molto dettagliata.

Una delle principali differenze tra /dev/diske /dev/rdisk, quando si accede ad essi dallo spazio utente, è che /dev/diskè memorizzata nel buffer. Il percorso di lettura / scrittura per /dev/disksuddividere l'I / O in blocchi 4KB, che legge nella cache del buffer, quindi copia nel buffer dello spazio utente (e quindi emette la successiva lettura 4KB ...). È bello in quanto puoi fare letture e scritture non allineate e funziona. Al contrario, /dev/rdisksostanzialmente passa semplicemente la lettura o la scrittura direttamente al dispositivo, il che significa che l'inizio e la fine dell'I / O devono essere allineati ai confini del settore.

Se fai una lettura o scrivi più grande di un settore in /dev/rdisk, quella richiesta verrà passata direttamente. Gli strati inferiori possono scomporlo (ad esempio, USB lo suddivide in pezzi da 128 KB a causa della dimensione massima del carico utile nel protocollo USB), ma in genere è possibile ottenere I / O più grandi ed efficienti. Durante lo streaming, come via dd, da 128 KB a 1 MB sono dimensioni abbastanza buone per ottenere prestazioni quasi ottimali sull'attuale hardware non RAID.

La memorizzazione nella cache eseguita dai /dev/diskpercorsi di lettura e scrittura è molto semplice e quasi senza cervello. Memorizza nella cache anche se non strettamente necessario; come se il dispositivo fosse in grado di mappare la memoria e trasferirlo direttamente nel buffer dell'app. Fa piccoli I / O (4KB), il che comporta un sacco di sovraccarico per I / O. Non legge né scrive dietro.

— aStruct
fonte

6

Sembra /dev/diske /dev/rdiskfunziona in modo diverso per HDD e SSD. Voglio controllarlo per la scheda MicroSD. Ho appena scritto l'immagine del disco da 2 GB su Sandisk Ultra MicroSD da 64 GB ( https://www.amazon.com/gp/product/B073JYVKNX ).

Test ripetuto più volte, ma i risultati sono rimasti stabili: 17MB / s per il /dev/diskvs 20 MB / s per /dev/rdisk. Passare bs=1ma non bs=16mdà assolutamente alcuna differenza nella velocità di scrittura.

Scrivere a /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)

Scrivere a /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)

Poi ho deciso di testare la velocità di lettura: 26MB / s per il /dev/diskvs 87MB / s per /dev/rdisk. Passare bs=1ma non bs=16mdà assolutamente alcuna differenza nella velocità di lettura.

Leggendo da /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)

Leggendo da /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)

— k06a
fonte

2

So che questo è un vecchio thread, ma altre persone potrebbero essere interessate alle implicazioni sulla velocità di ciò che ho provato. Voglio fare il backup del mio SSD interno nel mio MacBook Pro 13 "Retina (con un SSD Silicon Power da 1 TB) su un disco rigido USB 3.0 da 2,5" esterno, volendo catturare sia le partizioni macOS che BOOTCAMP. La mia riga di comando iniziale era:

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

I risultati sono stati una velocità di copia di ~ 31,3 MB / secondo. Era troppo lungo per farmi aspettare. Quindi, al secondo tentativo, la riga di comando era:

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

Usando /dev/rdiskinvece di /dev/diskaccelerare significativamente le cose, a circa 98,4 MB / secondo! Tuttavia, migliora ancora. Quindi, per il terzo tentativo, ho usato questa riga di comando:

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

L'opzione sparse dice a DD di non disturbare la scrittura su blocchi di output che sono tutti 0 sull'input. La cosa interessante è che questo diventa molto più veloce di quanto si pensi, anche mentre si è nel mezzo di aree "piene" del disco. Su qualsiasi unità che non è piena, avrai enormi blocchi di 0, accelerando ulteriormente DD. Fino ad ora, almeno, DD sta funzionando alla velocità di trasferimento teorica del mio hard disk: ~ 116,4 MB / secondo, e non ha ancora raggiunto quelle grandi aree vuote.

Prova queste opzioni: funzionano! Nota: cambiare ATTENTAMENTE if=e of=puntare correttamente alle unità corrette elencate da (per Mac):

diskutil list

— Mark J Foster
fonte

1

conv=sparseè fantastico quando si copiano i file.    Sarei preoccupato che potrebbe introdurre corruzione quando si copia un intero disco, una partizione o un  filesystem , a meno che non si sappia con certezza al 100% che il disco di destinazione non contiene altro che zero.

— G-Man,

1

Per la cronaca, almeno in macOS High Sierra, / dev / disk sembra essere molto più veloce di / dev / rdisk. Con dd o ddrescue, il mio confronto del throughput copiando da un HD magnetico a un SSD era di 3,7 Mbps usando / dev / rdisk e 45 Mb usando / dev / disk. Quindi, nelle versioni successive di macOS, potrebbe essere meglio usare / dev / disk invece di / dev / rdisk per le migliori prestazioni.

— JLG
fonte

2

Mentre scrivo un'immagine da 4,6 GB di estensione raspbian dallo spazio di archiviazione SSD interno su una scheda SD con dd e bs di 1 MB / dev / rdisk si comporta ancora molto più velocemente di / dev / disk su un macbook pro di fine 2013 con macOS 10.13.2. Ci sono voluti 27.16 minuti usando / dev / disk e solo 5.18 minuti usando / dev / rdisk.

— digitaladdictions

@digitaladdictions ha appena effettuato alcuni test sugli ultimi macOS: superuser.com/a/1346063/126537

— k06a

0

Penso prima di discutere quale nodo del percorso sia più veloce o tuffarsi in un test seriale. Dovremmo prendere in considerazione altri fattori che influenzeranno notevolmente la velocità finale di lettura / scrittura.

come le specifiche della scheda Micro SD, classe 4/10 / HC I ... chip e interfaccia lettore di schede SD, USB 1.1 / 2.0 / 3.0 / 3.1 memoria totale os / memoria libera, carico os, tipo hard disk os, HDD / SSD, HDD velocità di centrifuga e dimensione della cache, dimensione SSD / cache / spazio libero / interfaccia disco fisso os, ata / sata / esata,

se qualche fattore diventasse un collo di bottiglia, avremmo delle false conclusioni.

ecco il mio risultato: osx 10.12.6, ssd,

leggere microSD 16G da una scheda USB 2.0 leggere e scrivere su HDD esterno da 3,5 pollici tramite USB 3.0,

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

scrivere microSD 32G attraverso la lettura della scheda interna e l'origine dati è un HDD da 3,5 pollici esterno tramite USB 3.0,

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

puoi vedere, scrivi velocità> leggi velocità !!

— Vita digitale
fonte