Of device numbers, inodes, and our friend rdev

The mount structure contains a member called dev. The attributes structure contains two members: inode and rdev. Let's look at their relationships by examining a traditional disk-based filesystem. The filesystem is mounted on a block device (which is the entire disk). This block device might be known as /dev/hd0 (the first hard disk in the system). On this disk, there might be a number of partitions, such as /dev/hd0t77 (the first QNX filesystem partition on that particular device). Finally, within that partition, there might be an arbitrary number of files, one of which might be /hd/spud.txt.

The dev (or "device number") member, contains a number that's unique to the node that this resource manager is registered with. The rdev member is the dev number of the root device. Finally, the inode is the file serial number. (Note that you can obtain major and minor device numbers by calling rsrcdbmgr_devno_attach(); see the QNX Neutrino C Library Reference for more details. You are limited to 64 major devices and 1024 minor devices per major device.)

Let's relate that to our disk example. The following table shows some example numbers; after the table we'll take a look at where these numbers came from and how they're related.

Device dev inode rdev
/dev/hd0 6 2 1
/dev/hd0t77 1 12 77
/hd/spud.txt 77 47343 N/A

For the raw block device, /dev/hd0, the process manager assigned both the dev and inode values (the 6 and the 2 in the table above). The resource manager picked a unique rdev value (of 1) for the device when it started.

For the partition, /dev/hd0t77, the dev value came from the raw block device's rdev number (the 1). The inode was selected by the resource manager as a unique number (within the rdev). This is where the 12 came from. Finally, the rdev number was selected by the resource manager as well—in this case, the writer of the resource manager selected 77 because it corresponded to the partition type.

Finally, for the file, /hd/spud.txt, the dev value (77) came from the partition's rdev value. The inode was selected by the resource manager (in the case of a file, the number is selected to correspond to some internal representation of the file—it doesn't matter what it is so long as it's not zero, and it's unique within the rdev). This is where the 47343 came from. For a file, the rdev field is not meaningful.