Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

According to the rasbery pi documentation, You can load your OS to a flash card with either /dev/disk or /dev/rdisk.

rdisk stands for raw disk.

/dev/disk is a block level device, why would rdisk be 20 times faster?

Using Mac OSX

Note: In OS X each disk may have two path references in /dev: /dev/disk# is a buffered device, which means any data being sent undergoes extra processing. /dev/rdisk# is a raw path, which is much faster, and perfectly OK when using the dd program. On a Class 4 SD card the difference was around 20 times faster using the rdisk path.

share|improve this question
As a side note, I ran a test and rdisk actually took much longer. – spuder Aug 13 '13 at 22:26
As another side note, I felt I had to test too then, and found that an rdisk copy (via dd) was almost exactly 4 times faster than using the disk counterpart. – Travis Griggs Jan 7 '14 at 17:57
@TravisGriggs I'm curious which OS, Mac or linux? – spuder Jan 7 '14 at 18:06
Mac OSX 10.9.1 (MacBook Pro 15-inch, Early 2011) – Travis Griggs Jan 7 '14 at 19:13
I thought "rdisk" was a typo in some instructions for a Raspberry Pi SD card image I was reading. Upon further investigation I googled the difference and found this thread. Turns out in my case it was 13 times faster to write a 1.7GB image to an SD card using /dev/rdisk instead of /dev/disk! Macbook Pro Retina 13", early 2015 model. – tobias.mcnulty Aug 1 '15 at 0:48
up vote 47 down vote accepted

From man hdiutil:

/dev/rdisk nodes are character-special devices, but are "raw" in the BSD sense and force block-aligned I/O. They are closer to the physical disk than the buffer cache. /dev/disk nodes, on the other hand, are buffered block-special devices and are used primarily by the kernel's filesystem code.

In layman's terms /dev/rdisk goes almost directly to disk and /dev/disk goes via a longer more expensive route

share|improve this answer
why use disk when you can use rdisk? – user391339 Jan 4 '15 at 22:34
@user391339 Because caching is still a desirable thing. In cases where you have removable media, you want to get the data on the physical device as fast as possible, because you want the data in another physical location. Internal hard drives are a different story. You usually don't carry them around, so you don't care when the data is actually written to the device. When you cache data written to/read from devices that's a more expensive way of writing to the disk, but your programs are still faster, since they don't need to wait until all the data they want to write is written to the disk. – Kritzefitz May 12 '15 at 9:01

The accepted answer is right, but it doesn’t go into much detail.

One of the key differences between /dev/disk and /dev/rdisk, when you access them from user space, is that /dev/disk is buffered. The read/write path for /dev/disk breaks up the I/O into 4KB chunks, which it reads into the buffer cache, and then copies into the user space buffer (and then issues the next 4KB read…). This is nice in that you can do unaligned reads and writes, and it just works. In contrast, /dev/rdisk basically just passes the read or write straight to the device, which means the start and end of the I/O need to be aligned on sector boundaries.

If you do a read or write larger than one sector to /dev/rdisk, that request will be passed straight through. The lower layers may break it up (eg., USB breaks it up into 128KB pieces due to the maximum payload size in the USB protocol), but you generally can get bigger and more efficient I/Os. When streaming, like via dd, 128KB to 1MB are pretty good sizes to get near-optimal performance on current non-RAID hardware.

The caching being done by /dev/disk’s read and write paths is very simple and almost brain dead. It caches even if not strictly necessary; like if the device could memory map and directly transfer into your app's buffer. It does small (4KB) I/Os, which leads to a lot of per-I/O overhead. It does not do any read ahead or write behind.

share|improve this answer
Thanks for the addition – Daniël W. Crompton May 13 '15 at 9:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .