Linux文件系统的演变

Posted 2023-04-11

参考技术A

说起文件系统的演变与发展，不得不从最早期的 Minix 操作系统开始说起。

Minix(MINI-UNIX) 是早期的一个迷你版本的 「类UNIX操作系统」 ，由荷兰阿姆斯特丹自由大学计算机科学系的塔能鲍姆教授自行开发的可以与UNIX操作系统兼容的一个操作系统，因其小型，该操作系统被命名为 MINIX 。

MINIX 系统在设计之初，采用程序模块化的思想，将一众程序放在用户空间运行，而不是在操作系统的内核中运行。如 「文件系统」 和 「存储器管理」 等程序均是如此。

受 MINIX 操作系统的影响，早期的Linux操作系统也曾采用由塔能鲍姆教授开发的MINIX的文件系统。

然而，不只因为早期的 MINIX 操作系统并为真正意义上的开源软件(在保护著作的前提下进行收费)，而且基于 MINIX 的内部使用16位的偏移量，使文件系统能够支持的最大空间只有64MB，支持的最大文件名为14字符，导致后来 Linux 操作系统转而开发出了 ext(Extended File System) 第一代可扩展文件系统。

ext(Extended File System) 为Linux系统最早的扩展文件系统，采用 「UNIX文件系统」 的元数据结构，克服了 「MINIX」 操作系统性能不佳的问题。

ext 文件系统采用 虚拟文件系统(VFS) ，最大可支持2GB的文件系统。与 MINIX 文件系统不同的是， ext 可以使用最高2GB的存储空间并同时处理255个字符的文件名。

但，在 ext 文件系统中，文件创建时生成的 inode 信息是不变的，这导致文件发生修改后 inode 中储存的文件时间戳并不会发生变化；而且 ext 并不会为文件妥善分配空间，磁盘上的多个文件四散分布，严重制约了文件系统的性能。

ext 文件系统推出后不久，其开发者便意识到 ext 文件系统中存在很大缺陷( inode不变性 和 文件空间碎片化 )，并在一年后推出了 ext2 (Second Extened File System) 第二代扩展文件系统，用来代替 ext 文件系统。

ext2 吸取了 「UNIX文件系统」 的众多优点，并且因其良好的可扩展性( 为系统在磁盘上存储的数据结构预留了很多空间提供给开发者使用 )，在20世纪90年代众多文件系统中脱颖而出。

众多新的特性， POSIX(可移植操作系统接口) 、 访问控制表 等都是在这一代扩展文件系统上实现的。直至今天， POSIX 仍被众多操作系统所沿用。

不仅如此， ext2 还在 ext 的基础上进行了完善，能够最大支持的单个文件达到 2TB。

ext2 文件系统与20世纪90年代的众多文件系统一样，将数据写入到磁盘的过程中如果发生系统奔溃或断电，极容易导致文件损坏或丢失。

正是因为类似 ext2 等同时期的一众文件系统，在遭遇系统奔溃或断电时会出现文件损坏或丢失。尽管 ext2 文件系统拥有开机后对文件系统中文件的一致性校验，但校验的过程极为耗时，且校验的过程中，操作系统上的任何卷组都是不可访问的。

然而 ext2 遗留的问题在 ext3(Third Extended File System) 中得到了解决。

ext3 文件系统采用日志记录的方式，记录下了操作系统运行中的所有事件，这意味着即便遇到操作系统非正常关机后也无须对文件系统进行校验，从而防止了文件系统中数据丢失的可能。

尽管 ext3 使用日志系统进行记录文件系统的变化，但这并没有影响 ext3 文件系统处理数据的速度。基于日志系统在磁盘上的优化，在 ext3 中数据的传输效率是高于 ext2 的，并且可以通过重新设置日志的级别来提升文件系统的性能。

其次， ext3 在设计之初就吸收了 ext2 的很多思想，这使得 ext2 文件系统迁移到 ext3 变得极为便利。事实上， ext3 可以在从 ext2 迁移 ext3 的过程中，无须进行文件系统资料的备份，且无须担心升级后的数据恢复问题。

也正是因为 ext3 设计之初沿用了众多 ext2 的功能，这使得 ext3 缺乏变通。例如， 「inode的动态分配」 和 「可变块大小」 等问题并没有得到解决。不仅如此， ext3 文件系统在被挂载为写入时，无法对文件系统进行完整性校验。

第四代扩展文件系统( Fourth Extended File System, ext4 ) 是继 ext3 文件系统的后续版本，不仅支持 ext3 的日志文件体系 ，同样支持 大文件系统 ，不仅提高了文件系统对于存储碎片化的抵抗，而且改进了 inode固一化 的问题。

同时， ext4 文件系统在开发之初就考虑到很多问题，对众多问题的优化和改进也使得 ext4 拥有了众多新的特性。例如， 大文件系统 、 使用Extent文件存储的方式 、 预分配空间 、 延迟文件获取空间的时间 、 突破原有子目录限制 、 增加日志校验和 、 在线整理磁盘 、 文件系统快速检查 、 向下兼容其他ext文件系统`。

时至今天， ext4 文件系统已经成为Linux发行版默认使用的文件系统。

与 ext2 文件系统同一时期出现的，还有 xfs 文件系统。 xfs 文件系统是高性能的文件系统，最早在 IRIX 操作系统上开发，后期被移植到 Linux 操作系统上。现在所有的 Linux发行版 都支持 xfs 的使用。

相比 32位 Linux 的操作系统来说，64位 xfs 的文件系统能够支持的单个文件系统要远远超出 32位 操作系统。

xfs 对文件系统元数据提供了日志支持，当文件系统发生变化后，总是会保证源数据在数据块写入磁盘之前被写入日志中，磁盘中有一处缓冲区专门用来存放日志，从而不会影响正常的文件系统。

xfs 同样支持 「条带化分配」 。在条带化RAID阵列上创建 xfs 文件系统时，可以指定 条带化数据单元。通过配置条带化单元，使 数据分配、inode分配、日志等与RAID条带单元对齐，来提高文件系统的性能。

与 ext4 文件系统不同的是， xfs 文件系统还支持在线恢复。 xfs 文件系统提供了 xfsdump 和 xfsrestore 工具协助备份 xfs 文件系统中的数据。

以下为各文件系统的出现时间及特性：

参考自: https://zh.wikipedia.org/wiki/Ext4

I/O模型演变

文章目录

• 1 BIO
• 2 NIO
• 3 select
• 4 epoll

---

1 BIO

  在Linux系统早期，由于socket是阻塞的，用户进程需要阻塞等待请求到达，所以需要为每个socket开启一个进程。这时缺点显而易见，开启越多的进程则需要越多的内存，同时CPU的调度成本也会上升。

2 NIO

  随着Linux系统的不断完善，socket可以是非阻塞了。这时，用户空间只需要开启一个进程，轮询所有的socket，解决了BIO时期需要开启多个进程的问题。但是，这个方案依然有问题，如果有很多个socket，意味着用户进程需要访问多次内核调用，这依然需要很高的成本。

3 select

  当Linux有了select之后，用户进程可以一次把所有的socket文件描述通过select调用传递给内核，由内核遍历并筛选出就绪的socket文件描述符返回给用户进程，这样用户进程只需要遍历少量的文件描述符。

  但是，这个方案也有缺点，那就是用户空间和内核空间是通过select进行数据传输，而且select每次最多只能传输1024个文件描述符，这种用户空间和内核空间的来回拷贝数据也是需要很高的成本。

4 epoll

  epoll提供了三个系统调用：

• epoll_create：创建一个epoll实例并返回其文件描述符。
• epoll_ctl：往epoll中注册指定的文件描述符。
• epoll_wait：阻塞等待注册的事件发生，返回事件的数目，并将触发的事件写入events数组中。

  epoll相比于select，其优越之处在于，因为select每次调用时都要传递需要监控的所有socket给内核，这意味着需要将用户态的socket列表拷贝到内核空间，如果数以万计的句柄会导致每次都要拷贝几十几百KB的内存到内核态，非常低效。而我们调用epoll_wait时就相当于调用select，但是这时却不用传递socket句柄给内核，因为内核已经通过epoll_ctl拿到了要监控的句柄列表。
  epoll在初始化时，会开辟出epoll自己的内核高速缓冲区，用于存放每一个我们想监控的socket，这些socket会以红黑树的结构存储，以支持快速的查找、插入、删除。
  epoll的高效就在于，当我们调用epoll_ctl往里塞入百万个句柄时，epoll_wait仍然可以快速返回，并有效地将发生事件的句柄给用户进程。这是由于我们在调用epoll_create时，内核除了建立一个红黑树用于存储以后epoll_ctl传来的socket外，还会再建立一个list链表，用于存储准备就绪的事件。当我们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个句柄的中断到了，就把它放到准备就绪list链表里。所以，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。当epoll_wait调用时，仅仅观察这个list链表里有没有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常高效。
  而且，通常情况下即使我们要监控百万计的句柄，大多一次也只返回很少量的准备就绪句柄而已，所以，epoll_wait仅需要从内核态copy少量的句柄到用户态而已。