如果您是一位linux的初学者，建议你停下追逐的脚本，好好阅读本篇文章，linux文件系统与物理文件系统是学习linux的基础之基础，对你一定大有帮助。
文件系统是文件的管理者，决定文件如何被操作，比如存放、打开、关闭、写入、查找。文件可以是任何格式的数据，比如音频、视频、文档、代码、图片、应用程序、快捷方式等等。因为文件各种各样，所以文件系统的存在就很必要了。比如支持新建目录，新建空白文件，显示文件大小，显示文件创建日期，这些都是文件系统提供的服务。
文件系统结合图形操作界面，就造成了我们看到了双击就可以打开，单击就可以选中这些直观上的东西。除掉图形界面，文件系统依然可见。在linux命令行中，ls一下，会显示目录下的文件，ls -l一下，会显示文件的权限，文件的大小等等，这些都是文件系统提供支持的，如果没有文件系统，那么就没法创建文件，没法打开一个文件，我们保存在磁盘上的东西，就根本读不出来，磁盘对我们来讲就是一个谜。但是有了文件系统，我们就可以读出里面的数据。文件系统与其说是管理文件的，不如叫做磁盘驱动或者flash驱动、RAM驱动等等。没有文件系统，磁盘就是废品，没法使用。
Linux不像windows，仅仅只支持NTFS、FAT32等几个文件系统，linux支持的文件系统特别多，比如minix文件系统，iso9660（光盘用的），ext2，ext3，ext4（目前默认文件系统），resierfs，resier4，btrfs等等。不同的设备可以使用不同的文件系统，不同的文件系统侧重点不一样，在不同方面性能不一样。但是对于用户来讲，区别这些文件系统是很困难的，于是linux内核中引入了一层虚拟文件系统。虚拟文件系统负责统一各种不同种类的文件系统对用户提供的接口，使得可以使用同样的系统调用来操作不同文件系统上的文件。
如果我们调用open打开一个文档，那么不管这个文档存放于哪种设备上，也不管这种设备上运行的是哪种物理文件系统，都可以打开这个文件。事实上，我们没法站在用户层上区分是目前我们看到的文件是被哪种文件系统所支持的，因为linux内核的虚拟文件系统屏蔽了这些底层细节，使得不同的物理文件系统尽管管理文件的方式不同，但是用户看起来一模一样。如果想看具体究竟用得哪种文件系统，那么打开/proc/filesystems文件就可以看到目前系统中加载了多少种文件系统。
Linux与windows除了支持的文件系统数量不一样外，还有一个明显的组织结构的区别，这使得很多人用Linux相当不习惯。Windows操作系统支持多个分区，而且这几个分区是并列关系，比如可以将磁盘分为C、D、E、F等等很多个盘，而且每个盘可以进行不同的格式化（即安装不同的文件系统）。有几个文件系统，就有几个根目录，C：是一个，D：是一个，等等。但是linux不一样，linux不管分成多少个区，都只有一个根目录。
虚拟文件系统不存在于磁盘上，只存在于内存中。它本质上只是一种转换机制，将用户空间的请求映射到具体的物理文件系统上。物理文件系统则是实实在在的存在于磁盘中，并且占据一定的存储空间。每个文件系统都有且仅有一个超级块，该文件系统中的每个文件都有且仅有一个inode。超级块和inode都填好了数据。当你格式化一个磁盘的时候，该文件系统的超级块就已经填好了相关数据，并且占据了磁盘上的一定空间。当你新建一个文件的时候，该文件的inode中就已经记录了该文件的一切信息，比如存在磁盘哪里，建立时间，是否只读等等。
虚拟文件系统也有自己的数据结构，典型的有四个，超级块、inode、目录项、file。但是和物理文件系统中的结构不太一样。虚拟文件系统中这些结构没有自己的数据，其数据来源于物理文件系统。系统启动的时候，根据加载了哪些文件系统，内核会用实际的物理文件系统的超级块填充内存中虚拟文件系统的超级块；inode也是根据物理文件系统中的数据填充的；目录项结构体是根据路径名现场建立的；file是打开一个文件的时候现场分配并填充的。虚拟文件系统中结构体的一切数据都来源于物理文件系统，当系统关闭的时候，物理文件系统依然待在磁盘上，虚拟文件系统则会消失。
用户的程序实际上只和虚拟文件系统打交道，不和物理文件系统打交道。虚拟文件系统中普遍使用了内核链表这种结构体。超级块、inode、目录项、file这四大结构体都会构成双向链表。构成链表的关键在于结构体中有head_list的结构体，head_list使得不同的结构体居然也可以串成链表。有的结构体中包含多个head_list，根据不同的需求，同一数据结构会存在于多个链表中，而且同一链表中的结构体可能五花八样。
虚拟文件系统本身只提供用户操作文件的接口，比如open函数，close函数，但是并不负责这些函数的实现，这些函数怎么实现的，即文件究竟是怎么打开的，怎么写入，怎么关闭的，是由物理文件系统提供的。同样是open，每个物理文件系统的实现函数并不一样。我在2.6.29内核中追踪了open系统调用的实现，得到了如下路径：
Open系统调用——>sys_open函数——>do_sys_open函数——>do_filp_open函数——>nameidata_to_filp函数——>__dentry_open函数，在该函数中找到了至关重要的一句话：open = f->f_op->open;
左边的open就是虚拟文件系统提供的open函数，右边的f_op->open则是f结构体（file类型）所在文件系统的open操作函数。这说明打开该文件的具体操作是由该文件所在文件系统提供的。
内核代码极其复杂，追踪代码是有技巧的，如果一个函数要返回file结构，那么在它的实现代码中，最值得关注的就是同样返回file的函数，其他的函数都是旁枝末节。所以追踪代码要始终留心提供返回值的函数，它往往实现核心功能。