How a mount point directory entry is different from an usual directory entry in a filesystem

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.