I'm still confused about the concept of kernel and filesystem.

Filesystems contain a table of inodes used to retrieve the different files and directories in different memories.

Is this inode table part of the kernel? I mean, is the inode table updated when the kernel mounts another filesystem?

Or is it part of the filesystem itself that the kernel reads by somehow using a driver and inode table address?

2 Answers 2


There is some confusion here because kernel source and documentation is sloppy with how it uses the term 'inode'.

The filesystem can be considered as having two parts -- the filesystem code and data in memory, and the filesystem on disk.

The filesystem on disk is self contained and has all the non-volatile data and metadata for your files. For most linux filesystems, this includes the inodes on disk along with other metadata and data for the files.

But when the filesystem is mounted, the filesystem code also keeps in memory a cached copy of the inodes of files being used. All file activity uses and updates this in memory copy of the inode, so the kernel code really only thinks about this in memory copy, and most kernel documentation doesn't distinguish between the on disk inode and the in memory inode. Also, the in memory inode contains additional ephemeral metadata (like where the cache pages for the file are in memory and which processes have the file open) that is not contained in the on disk copy of the inode. The in memory inode is periodically synchronized and written back to disk. The kernel does not have all the inodes in memory -- just the ones of files in use and files that recently were in use. Eventually inodes in memory get flushed and the memory is released. The inodes on disk are always there.

Because file activity in unix is so tightly tied to inodes, filesystems (like vfat) that do not use inodes still have virtual inodes in kernel memory that the filesystem code constructs on the fly. These in memory virtual inodes still hold file metadata that is synchronized to the filesystem on disk as needed.

In a traditional unix filesystem, the inode is the key data structure for a file. The filename is just a pointer to the inode, and an inode can have multiple filenames linked to it. In other filesystems that don't use inodes, a file can typically only have one name and the metadata is tied to the filename rather than an inode.

  • So to understand, mounting a filesystem consist of adding acached copy of the inodes of files being used in the RAM area of the filesystem driver? I'm I right? What else is done by the kernel during mounting? I'm also confused about what mounting a filesystem means Jun 4, 2022 at 12:17
  • 2
    No. Mounting the filesystem attaches it to a directory. The filesystem typically also has a "superblock" that has metadata relevant to the whole filesystem and that is loaded into memory. For some filesystems, mounting may also trigger the filesystem kernel code module to be loaded into memory. (Critical filesystem types might have that code permanently loaded instead.) The inodes are only loaded into memory as the files they are associated with are used.
    – user10489
    Jun 4, 2022 at 12:20
  • 2
    What else is done when mounting? A cursory filesystem check is done to make sure the filesystem is sane before mounting it. In journaled filesystems, the journal from the last mount would be examined and uncommitted data may be replayed and repaired. Once all that is complete, the filesystem is marked as "dirty" (meaning it is currently in use). When it is unmounted, this dirty flag (in the superblock) is cleared. That way, if the system is rebooted without unmounting filesystems, they can be examined more closely for errors on next mount.
    – user10489
    Jun 4, 2022 at 12:23
  • @makouda: No, the VFS cache is only populated with inode data as they're accessed. The data on disk is the master copy, so dirty data in RAM is synced after some time and when there's available bandwidth, making it possible for the kernel to evict entries from its cache when it needs memory for other things. The inode cache is (at a high level) quite similar to the pagecache for file data: both write-back caches that sync themselves to the filesystem so your precious data isn't only in RAM indefinitely. And obviously RAM size can be much smaller than disk. Jun 4, 2022 at 21:24
  • also note that inode numbers are per-filesystem. So you can have multiple inodes numbered 12345, one of each filesystem (it is triplet MAJOR, MINOR, INODE that is unique -- where the MAJOR/MINOR identify block device where filesystem is on -- those are that two numbers you see for block devices when you do ls -l /dev/sd*) Jun 6, 2022 at 11:19

The inodes, free blocks etc. are handled by the file system driver. This file system code provides a generic interface to the kernel which means the kernel can access files on a range of file systems without adaptation on this "user side".

Many file system drivers, however, are also contained within the kernel (in a separate region of the source code). This includes the drivers and logic for the ext4 and other Linux native file systems.

If a second file system is mounted a further instance of this file system (data structure in RAM) is generated, so each disk partition is handled separately from the other. File access on two disk may use the same driver code (e.g. routines for the ext4 file system) but with different data.

The file system driver itself just needs a block device access below it ("read block 17", "write block 23") which means it can sit on top of a disk, partition, LUKS or LVM abstraction layers etc. without modification.

  • If a second file system is mounted a further instance of this file system (data structure in RAM) is generated: you mean a data structure containing information like inodes and it's generated inside the filesystem driver RAM area? Jun 4, 2022 at 11:10
  • 1
    @makouda Yes, most of the time. Generally, each file system determines the necessary data by itself. In the end all information is stored on the disk itself, including all inodes. Drivers will cache some of that information in RAM, perhaps the FAT in FAT-based systems, master inode(s), free space but also which block device is used etc..
    – Ned64
    Jun 4, 2022 at 11:21
  • Technically, the inode cache is generally not situated in "filesystem RAM area", but is global for whole kernel (and you can see its usage by using slabtop(1) - most notable global filesystem-related caches are inode_cache and dentry, but there are sometimes additional filesystem-type specific ones, like ext4_inode_cache ). Although in Linux, filesystem code is not privilege-separated from rest of the kernel code (e.g. both reside in ring 0 on x86 architecture), so "filesystem RAM area" is just part of "generic kernel RAM area" Jun 6, 2022 at 11:27

You must log in to answer this question.

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