How Linux kernel sees the filesystems
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?
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.
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.