Device files are not files per se. They're an I/O interface to use the devices in Unix-like operating systems. They use no space on disk, however, they still use an inode as reported by the stat command:

$ stat /dev/sda
      File: /dev/sda
      Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 6h/6d   Inode: 14628       Links: 1     Device type: 8,0

Do device files use physical inodes in the filesystem and why they need them at all?

  • 2
    The inode and the data are the file. Without an inode, you have no file. (Device files don't have any data though) Commented Aug 8, 2017 at 9:43

4 Answers 4


The short answer is that it does only if you have a physical filesystem backing /dev (and if you're using a modern Linux distro, you probably don't).

The long answer follows:

This all goes back to the original UNIX philosophy that everything is a file. This philosophy is part of what made UNIX so versatile, because you could directly interact with devices from userspace without needing to have special code in your application to talk directly to the physical hardware.

Originally, /dev was just another directory with a well-known name where you put your device files. Some UNIX systems still take this approach (I believe OpenBSD still does), and you can usually tell if a system is like this because it will have lots of device files for devices the system doesn't actually have (for example, files for every possible partition on every possible disk). This saves space in memory and time at boot at the cost of using a bit more disk space, which was a good trade off for early systems because they were generally very memory constrained and not very fast. This is generally referred to as having a static /dev.

On modern Linux systems (and I believe also FreeBSD and possibly recent versions of Solaris), /dev is a temporary in-memory filesystem populated by the kernel (or udev if you use Systemd, because they don't trust the kernel to do almost anything). This saves some disk space at the price of some memory (usually less than a few MB) and a very small processing overhead. It also has a number of other advantages, with one of the biggest being that it's easier to detect hot-plugged hardware. This is generally referred to as having a dynamic /dev.

In both cases though, device nodes are accessed through the regular VFS layer, which by definition means they have to have an inode (even if it's a virtual one that just exists so that stuff like stat() works like it's supposed to. From a practical perspective, this has zero impact on systems that use a dynamic /dev because they just store the inodes in memory or generate them as needed, and near zero impact where /dev is static because inodes take up near zero space on-disk and most filesystems either have no upper limit on them or provision way more than anybody is likely to ever need.

  • 4
    Cautiously raises hand. I've been on a project that had a server run out of inodes. It was finally the crisis our team needed to convince management to invest in replacing that back-end system, which had been designed (poorly, as you might imagine!) before any of us had gotten there.
    – KRyan
    Commented Aug 7, 2017 at 20:29
  • @KRyan It can happen, but these days it's rare unless the admin explicitly reduced the number at filesystem creation. Many modern filesystems (at least NTFS, BTRFS, and ZFS, I think XFS might too) actually allocate inodes dynamically, so on a lot of newer systems, it's actually impossible to run out. Commented Aug 7, 2017 at 20:57
  • @KRyan I too have had that problem. And it was actually a well designed system, if a bit dated and taken to extreams (each transaction required an independent log, that was kept on disk, eventually it just filled up with tiny little inodes)
    – coteyr
    Commented Aug 7, 2017 at 21:52
  • 1
    Od and docker is kind of Famous for causing exactly this inode problem.
    – coteyr
    Commented Aug 7, 2017 at 21:53
  • @AustinHemmelgarn The ext family is rather infamous for having a static number of inodes (and subsequently running out). It is also, incidentally, the most used Linux filesystem by probably a huge margin (scenarios that store huge amounts of data on XFS aside, with ZFS and BTRFS being relatively new), and the default for most distros. Of course, in a modern system, the default max inodes is many orders of magnitude larger than the number of device files you'll ever have.
    – Bob
    Commented Aug 8, 2017 at 0:44

Device files have permissions, too, and those are stored in an inode.

  • Excellent point that I forgot to mention. Commented Aug 7, 2017 at 20:53
  • 5
    Not just permissions, but also the file type and other metadata. Classically, the directory itself only contains the name and the inode number — there's nothing indicating that the file is a device until you read the inode. Commented Aug 7, 2017 at 23:19

Directories are simply a mapping from filenames to inodes, so everything about the thing that the name refers to (a file, a symlink, a device, a FIFO, a socket) has to be in the inode, there's nowhere else to put it.

Information about the device is stored in the inode. The major and minor device numbers are there, so are permissions, timestamps, etc. The type field that says that it's a block or character device rather than a regular file is stored there.

The inode for devices simply doesn't make use of the fields that contain the block map of the file.


Without an inode you'd only have the file name to hold all the information about the device in question. This means "nice" device names like /dev/sda would be out of the question: you'd need a name that could be tied to a particular driver, like /dev/ohci/sda.

Even more importantly, all tools which rely on inodes (like stat, ls and so on) would have to be modified to treat paths under /dev in a special way. That would be a prohibitively large amount of work with no apparent benefit compared to current state of things.

You must log in to answer this question.

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