I know that a directory is a file contained rows kind of “name = inode number”.

When I request a path like /home/my_file.txt, next steps take place:

  1. Go to inode number 2 (root directory default inode)
  2. Get file to which inode #2 is pointing.
  3. Search through this file and find “home” entry. Get its inode number, for example 135.
  4. Get file to which inode #135 is pointing.
  5. Search through this file and find “my_file.txt” entry. Get its inode number, for example 245.
  6. Get file to which inode #245 is pointing.

The question: how this process is different in case the home directory is the mount point of another filesystem, residing on another block device? When system understand, that this directory is the mount point and how it do that? Where this information is stored - in the inode, in the directory file or somewhere else?

For example, part of my root directory listing with inode numbers displayed:

ls -d1i /*/

inode # name
656641  /bin/
2       /boot/
530217  /cdrom/
2       /dev/
525313  /etc/
2       /home/
393985  /lib/

Here, home and boot directories are mount points and resided on own filesystems. Run my pseudocode algorithm (written above) and stuck on the step number 3 - in this case, home inode number is 2 and it is located in another filesystem and in another block device.

  • Those six steps, is that something you believe is happening, or can you point to a kernel source file? – Kusalananda May 9 '17 at 17:01
  • Conceptually there's a step 2½, which is along the lines of "Check if this is a mountpoint. If it is then switch device context to this new filesystem, open the directory for the root inode (either 1 or 2; I can't remember), and continue..." – roaima May 9 '17 at 17:11
  • @Kusalananda It is how i imagine this process. Certainly, not exact execution algorithm. I thought add "in my opinion" in the brackets, but decided that it is not necessary. – MiniMax May 9 '17 at 17:12
  • The mount point inodes, are the / inodes of the mounted file systems. To see the real inode numbers you have to umount all or bind mount / to somewhere else. Also see the struct stat has fields st_dev (ID of device containing file) and st_ino (inode number) – rudimeier May 9 '17 at 17:14
  • 1
    Can this be answered in general by anything other than "It's the job of the kernel to know what directories are mount points"? I wouldn't make any assumptions about the specific implementations in Linux, *BSD, Solaris etc. being either similar or different from each other. One way to do it would be to have a table of those [filesystem, inode number] pairs that represent mount points, and then lookup there every time you meet a directory. Or store the mountpoints by path or file name, which might be problematic in many ways but possibly doable in some way on some sort of system. – ilkkachu May 9 '17 at 17:42
up vote 5 down vote accepted

Your description of the process isn't quite right.

The kernel keeps track of which paths are mount points. Exactly how it does that varies between kernel, but typically the information is stored in terms of paths. For example the kernel remembers “/ is this filesystem, /media/cdrom is this filesystem, /proc is this filesystem”, etc. Typically, rather than a table mapping path strings to data structures representing mounted filesystems, the kernel stores tables per directory. The data associated with a directory entry is classically called a dentry. There's a dentry for the root, and in each directory there's a dentry for each file in that directory that the kernel remembers. The dentry contains a pointer to an inode structure, and the inode contains a pointer to the filesystem data structure for the filesystem that the file is on. At a mount point, the associated filesystem is different from the parent dentry's associated filesystem, and there's additional metadata to keep track of the mount point. So in a typical unix kernel architecture, the dentry for / contains a pointer to information about the root filesystem, in addition to a pointer to the inode containing the root directory; the dentry for /proc (assuming that it's a mount point) contains a pointer to information about the proc filesystem, etc. If /media/cdrom is a mount point but not /media, the kernel remembers in the dentry for /media that it isn't allowed to forget about it: remembering about /media isn't just a matter of caching for performance, it's necessary to remember the existence of the mount point /media/cdrom.

For Linux, you can find documentation in the kernel documentation, on this site and elsewhere on the web. Bruce Fields has a good presentation of the topic.

When the kernel is told to access a file, it processes the file name one slash-separated component at a time and looks up the component each time. If it finds a symbolic link, it follows it. If it finds a mount point, no special processing is actually necessary: it's just that the inodes are attached to a different directory.

The process does not use inode numbers, it follows pointers. Inode numbers are a way to give a unique identity to each file on a given filesystem outside of the kernel: on disk, and for applications. There are filesystems that don't have unique inode numbers; filesystem drivers normally try to make up one but that doesn't always work out, especially with network filesystems (e.g. if the server exports a directory tree which contains a mount point, there may be overlap between the set of inodes above and below that mount point). Rows that map name to inode number are the way a typical on-disk filesystem works if it supports hard links; filesystems that don't support hard links don't really need the concept of inode number.

Note that information about mount points is stored only in memory. When you mount a filesystem, this does not modify the directory on top of which the filesystem is mounted. That directory is merely hidden by the root of the mounted filesystem.

I'm not sure this can be answered in general, as it's an implementation issue. Of course, the OS has to somehow know that a given directory is a mount point, but it's up to the OS writers to consider how this is done. I have no idea of the internals of, say, Linux, *BSD, Solaris, or whatever and I wouldn't dare assume any similarities or differences between them.


As a guess, I think we can uniquely identify an inode by the {device, inode} pair (st_dev and st_ino in struct stat). Assuming hard links to directories are forbidden, a directory inode would also have a unique name.

Hence, one way would be to have a table of all mount points in the system, which the OS would then check for each and every directory when walking a path.

If the system would have some sort of cache for inodes (a useful optimization), we could skip the full table search by adding a flag or pointer in the in-memory inode structure to tell if that inode is a mount point or not.

  • We already have a table of file system mount points. 2, in fact: fstab (file systems table) and mtab (mounted file systems table). Both are used to determine which device is where in the directory tree. – Mioriin May 9 '17 at 20:28
  • “we can uniquely identify an inode by the {device, inode} pair” — not always. This is true with “native” Unix filesystems, but not guaranteed in general. The kernel, in particular, can't make this assumption. – Gilles May 9 '17 at 21:55
  • @Mioriin /etc/fstab is a configuration file. It doesn't reflect the current state of the system. /etc/mtab, if it's a regular file and not a link to /proc/mounts, normally contains data written by the mount command, but could be edited independently. /proc/mounts contains actual live data served by the kernel — which shows that the kernel maintains the data that it serves there. – Gilles May 9 '17 at 21:57
  • @Gilles, like I said, just speculating. A system without stable inode numbers would need to do something else (for the whole filesystem in question, probably). – ilkkachu May 9 '17 at 22:21
  • @ilkkachu Inode numbers are mostly useful to keep track of hard links. Filesystems without hard links have no use for this concept. – Gilles May 9 '17 at 22:25

When a filesystem in mounted at a particular mount-point, OS reads Super-block from the mounted filesystem loads it in memory. A Super-block, along with many other things has information regarding the inode of the root of that filesystem.

The points made above are correct that there are OS data structures that keeps record of all mounted filesystems, if another filesystem has been mounted at /home/, that filesystem's Super-block will be consulted to get its root directory's inode number.

  • This doesn't answer the question: how does the OS know where mount points are? – Gilles May 9 '17 at 21:58
  • Read my answer again you will find it there that kernel knows which devices are mounted where. Or, do cat /proc/mounts. As another files system is mounted on /home/ in this case, inode 2 showing up against /home/ represents root directory of that mounted file system. – Zul K Irshad May 9 '17 at 22:53

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.