Why is /dev a subdirectory of / (the root)? I ask because isn't everything in the file system also mounted from the computer's hard disk which show up in /dev? Then why isn't dev the root directory and then all the disks will show up there.

  • 1
    When you say "isn't everything in the file system also mounted from the computer's hard disk" I don't really know what you mean. I guess your root filesystem is probably (but not necessarily) from a block device which appears in /dev, but this does not usually pose a problem. Are you referring to the bootstrap problem (how to mount anything at boot time before anything is mounted)? If yes, then the details depend on the OS (and sometimes distro) which you didn't specify...
    – Celada
    May 1, 2016 at 15:52

3 Answers 3


I believe Unix V1 would be run from a single disk. It had no real VFS. You can find the system filesystem at the root of the namespace, /. No indirection required; no SYSTEMROOT = c:/windows variable. Remember this was hand-written assembly code. Minimalist ideas were very useful.

The ideas here are often described in terms of their elegance. I want to run /bin/ls from the running system, or read the contents of /etc/motd. I don't need to think about how the disk is called every time (DOS' C:).

Drive letters on DOS / CPM actually pre-date their implementation of a hierarchical filesystem. But you could also consider them as a user interface feature which made different tradeoffs, for systems which made very heavy use of filesystems on floppy disks. In fact, you can run a DOS system disk, remove it, and continue using the DOS shell to run programs on a second disk. So you do end up wanting a way to refer to drives that doesn't depend on special files from the system filesystem, because you don't exactly have a system filesystem that's mounted all the time.

Drive letters don't appear to have much relevance on modern systems; Unix is feeling somewhat smug here :).

Unix V1 already had paths like /dev and /etc that people and code were internalizing. Also from the beginning, mount was used for "detachable filesystems".

(A second disk /usr was used in subsequent versions. The search path - PATH environment variable - was added to support the second bin directory, /usr/bin.)

Messing around with the standard paths is generally a cause for excessive drama (even when there's a good reason). They've been reformed somewhat over time, and you can see this in Linux. But no-one found a compelling reason to e.g. stick C: in front of everything.


It's a convention. Simply called Filesystem Hierarchy Standard. There is nothing more to it.



This is because the device files you find in /dev aren't actually mount points *. They're just handy filesystem-based references to access the devices themselves. You can see a similar sort of hierarchy under /sys — particularly, look in /sys/block.

Why is something like /dev/sda a special type of file rather than a directory under which there are subdirectories for different partitions, and then the filesystem contents of those partitions under that? It's mostly just because. The designers of Unix could have done something like that, but this is what they did instead.

Why /dev instead of just putting the device files in / directly? Well, there's a lot of files in there. It would look ugly. You could do it if you want, though. Take a look at, for example, /dev/sda:

$ ls -l /dev/sda
brw-rw----. 1 root disk 8, 0 Apr 27 23:18 /dev/sda

The b at the beginning indicates that this is a block device, and the "8, 0" are the major and minor device numbers — basically magic, predefined numbers which the kernel knows correspond to a particular driver.

You can create these wherever you want. For example:

$ sudo mknod /tmp/this-is-my-main-disk-drive b 8 0
$ ls -l /tmp/this-is-my-main-disk-drive 
brw-r--r--. 1 root root 8, 0 May  1 14:31 /tmp/this-is-my-main-disk-drive
$ sudo fdisk -l /tmp/this-is-my-main-disk-drive
Disk /tmp/this-is-my-main-disk-drive: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Note, though, that I've created a major security hole, since this device is now readable by everyone on the system. Don't do that.

* well, except for a few things which are, but for simplicity's sake let's ignore them right now.

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