mik*_*mik 8 filesystems kernel inode
我仍然对内核和文件系统的概念感到困惑。
文件系统包含一个索引节点表，用于检索不同内存中的不同文件和目录。
这个索引节点表是内核的一部分吗？我的意思是，当内核挂载另一个文件系统时，inode 表是否会更新？
或者它是内核通过某种方式使用驱动程序和索引节点表地址读取的文件系统本身的一部分？
use*_*489 23
这里存在一些混乱，因为内核源代码和文档对于术语“inode”的使用方式很草率。
文件系统可以被认为有两部分——内存中的文件系统代码和数据，以及磁盘上的文件系统。
磁盘上的文件系统是独立的，并且具有文件的所有非易失性数据和元数据。对于大多数 Linux 文件系统，这包括磁盘上的 inode 以及文件的其他元数据和数据。
但是，当安装文件系统时，文件系统代码还会在内存中保留正在使用的文件的 inode 的缓存副本。所有文件活动都使用并更新 inode 的内存副本，因此内核代码实际上只考虑内存副本，并且大多数内核文档不区分磁盘 inode 和内存 inode。此外，内存中的索引节点还包含额外的临时元数据（例如文件的缓存页面在内存中的位置以及哪些进程打开了该文件），这些元数据不包含在索引节点的磁盘副本中。内存中的索引节点会定期同步并写回磁盘。内核并没有内存中的所有索引节点——只有正在使用的文件和最近使用的文件的索引节点。最终内存中的索引节点被刷新并释放内存。磁盘上的索引节点始终存在。
由于 UNIX 中的文件活动与 inode 紧密相关，因此不使用 inode 的文件系统（如 vfat）仍然在内核内存中具有文件系统代码动态构建的虚拟 inode。这些内存中的虚拟 inode 仍然保存根据需要同步到磁盘上的文件系统的文件元数据。
在传统的unix文件系统中，inode是文件的关键数据结构。文件名只是指向 inode 的指针，一个 inode 可以链接多个文件名。在其他不使用索引节点的文件系统中，一个文件通常只能有一个名称，并且元数据与文件名而不是索引节点相关联。
索引节点、空闲块等由文件系统驱动程序处理。该文件系统代码为内核提供了通用接口，这意味着内核可以访问一系列文件系统上的文件，而无需在此“用户端”进行调整。
然而，许多文件系统驱动程序也包含在内核中（在源代码的单独区域中）。这包括 ext4 和其他 Linux 本机文件系统的驱动程序和逻辑。
如果安装了第二个文件系统，则会生成该文件系统的另一个实例（RAM 中的数据结构），因此每个磁盘分区都将彼此分开处理。两个磁盘上的文件访问可以使用相同的驱动程序代码（例如，ext4 文件系统的例程）但具有不同的数据。
文件系统驱动程序本身只需要其下方的块设备访问（“读块 17”、“写块 23”），这意味着它可以位于磁盘、分区、LUKS 或 LVM 抽象层等之上，无需修改。