Understanding /dev/

Question

Level 1

105 points

Understanding /dev/

Hi,

I tried some searches on this but was unsuccessful. I'm looking for a brief explanation of the /dev/ directory. I'm learning about FreeBSD right now, from which Apple used some code and have found a lot of similarities. I realize that /dev/ houses device nodes and such, but specifically I'm wondering what the difference is between disk0 and rdisk0. It seems that both are synonymous to me. For example if I plug in my external hard drive (gets mounted as /dev/disk1s2 and /dev/rdisk1s2) I can do both:

sudo gpt show disk1
sudo gpt show rdisk1

and I get the same thing.

On a similar note, I'm reading about the FreeBSD vinum volume manager and wondered if OS X uses something like this. I'm not sure why /Volumes/ hdName exists... it is just a symlink to / from what I can see when doing 'ls -l /Volumes/'.

Anyway, I tried to figure this out but have not succeeded in my googling. Could anyone chime in on /dev/ and how OS X treats the /Volumes/ directory or its purpose?

Thanks!

-John

MacBook 2,1, Mac OS X (10.5.5), Dual booting FreeBSD

Posted on Jan 3, 2009 3:34 PM

Reply

Answer 1

BobHarris

Level 9

56,789 points

Jan 3, 2009 5:38 PM in response to John Hendy

I'm wondering what the difference is between disk0 and rdisk0.

If you use *ls -l* on the devices you will see a difference


 ls -l /dev/*disk0
brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0
crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0

disk0 has b as the device type which indicates it is a Block device.

rdisk0 has c as the device type which indicates it is a Character device.

In this case Character for a disk means access via this device means it is a Raw device interface.

So far I have not really told you anything. Just introduced new terms.

BEFORE I GO ON. I do not know if Mac OS X device drivers behave the way I'm about to describe.

A Raw device driver (for disks) MUST perform I/O operations that start on sector boundaries. Write operations MUST uses sizes that are exact multiples of a sector. Reads could be less than an exact multiple of a sector, but generally it is also done in exact multiples as well (typically a sector is 512 bytes, but that is not an absolute).

A Block device driver allows the caller to read and write using sizes that are not exact multiples of 1 sector, starting on sector boundaries. The Block device driver will provide buffering, and even caching of disk sectors.

A Raw/Character deivce driver transfers data directly from the device controller to the caller's buffer. A Block device driver firsts transfers the data to a system buffer, and then the data is transferred to the caller's buffer.

The advantage of a block device is data caching and allowing reads and writes to occur on in something less than exact sectors.

The advantage of a Raw/Character device driver is that there is no extra software between the device and the application. Applications that perform their own buffering (think databases) do not want their data double buffered. They would prefer to get the operating system out of the way.

Now from your stand point, you access the disk via a file system which will use the device driver that makes the most sense to that file system implementation.

I'm learning about FreeBSD right now, from which Apple used some code and have found a lot of similarities.

Mac OS X device drivers are totally different from FreeBSD. Mac OS X implemented its own device driver architecture.

I'm reading about the FreeBSD vinum volume manager and wondered if OS X uses something like this. I'm not sure why /Volumes/ hdName exists... it is just a symlink to / from what I can see when doing 'ls -l /Volumes/'.

I do not think so. Again because the volume manager is generally a layered device driver, and as I said Mac OS X implemented its own device driver architecture and wrote their own drivers. The closest thing to a volume manager is the RAID driver in Mac OS X.

/Volumes is the a Mac OS X convention for placing automatically mounted file systems. They have to go somewhere. The boot device is a file system, but since the boot file system is / you can not be both / and /volumes/yourdiskname. But you can put a symlink in /Volumes. Plus / is not your volume name. But the symlink name in /Volumes can be your boot volume's name.

Reply

Answer 2

John Hendy Author

Level 1

105 points

Jan 5, 2009 5:50 AM in response to BobHarris

Thanks for the in depth answer! After you referenced 'block' and 'character' devices I recalled reading about them in 'The Complete FreeBSD' and went back and re-read the section. It was still a bit over my head, but correlated very well with what you said. Block devices, as you said, can have advantages, but it sounded like it puts the buffer on the kernel and there was no way for the application to know when the data had been synced from the buffer to the actual disk and flushed from cache. Character devices put the write in the responsibility of the application itself, guaranteeing awareness of the completion or the write to disk.

Re. the volumes question... so if I understand correctly, my 'volume' isn't the same as the sense of the FreeBSD volume, it's just a way to have a name associated with / via symlink?

Thanks a ton for your time! Well, well, well answered.

-John

Reply

Answer 3

BobHarris

Level 9

56,789 points

Jan 5, 2009 6:19 AM in response to John Hendy

Most (just about everybody) uses a file system. File systems are frequently layered on block devices. The most common case of using a raw disk is a commercial database (such as Oracle) where the entire disk (lots of disks) are dedicated to the exclusive use of the databae.

Using a block device with Operating System buffering and caching has hugh performance advantages, as data is reread far more often than written. Only really high performance application toto the trouble of implementing their own cache and want to bypass the OS cache.

An application that wants to insure it's data is on disk has several options to force the flushing of modified data to disk. And most file systems will flush modified data to disk within 30 seconds of being modified, if not sooner.

Reply