文件系统篇

目录

1.文件系统的基本组成

1.1.文件

1.1.1.目录项和目录是一个东西吗？

1.1.2.那文件数据是如何存储在磁盘的呢？

2.page cache

2.1.进程写文件时，进程发生了崩溃，已写入的数据会丢失吗

2.2.page cache是什么？

2.3.page和page cache

2.4. Page Cache 与 buffer cache

---

自己理解：文件系统、文件系统，顾名思义，是为了将「文件」组织起来，构成一个系统。文件是主体，是文件系统的基本数据单位。

1.文件系统的基本组成

文件系统是操作系统中负责管理持久数据的子系统，说简单点，就是负责把用户的文件存到磁盘硬件中，因为即使计算机断电了，磁盘里的数据并不会丢失，所以可以持久化的保存文件。

文件系统的基本数据单位是文件，它的目的是对磁盘上的文件进行组织管理，那组织的方式不同，就会形成不同的文件系统。

Linux 最经典的一句话是：「一切皆文件」，不仅普通的文件和目录，就连块设备、管道、socket 等，也都是统一交给文件系统管理的。

1.1.文件

Linux文件系统为每个文件分配2个数据结构：索引节点（index node）和目录项（directory entry），它们主要用来记录文件的元信息和目录层次结构。

• 索引节点，也就是 inode，用来记录文件的元信息，比如 inode 编号、文件大小、访问权限、创建时间、修改时间、数据在磁盘的位置等等。索引节点是文件的唯一标识，它们之间一一对应，也同样都会被存储在硬盘中，所以索引节点同样占用磁盘空间。
• 目录项，也就是 dentry，用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来，就会形成目录结构，但它与索引节点不同的是，目录项是由内核维护的一个数据结构，不存放于磁盘，而是缓存在内存。

1.1.1.目录项和目录是一个东西吗？

不是一个东西

1. 目录是个文件，持久化存储在磁盘
2. 目录项是内核一个数据结构，缓存在内存

如果查询目录频繁从磁盘读，效率会很低，所以内核会把已经读过的目录用目录项这个数据结构缓存在内存，下次再次读到相同的目录时，只需从内存读就可以，大大提高了文件系统的效率。

1.1.2.那文件数据是如何存储在磁盘的呢？

磁盘进行格式化的时候，会被分成三个存储区域，分别是超级块、索引节点区和数据块区。

• 超级块，用来存储文件系统的详细信息，比如块个数、块大小、空闲块等等
• 索引节点区，用来存储索引节点
• 数据块区，用来存储文件或目录数据

我们不可能把超级块和索引节点区全部加载到内存，这样内存肯定撑不住，所以只有当需要使用的时候，才将其加载进内存，它们加载进内存的时机是不同的：

• 超级块：当文件系统挂载时进入内存；
• 索引节点区：当文件被访问时进入内存

2.page cache

2.1.（面试题）进程写文件时，进程发生了崩溃（操作系统还未崩溃），已写入的数据会丢失吗

面试题：当向磁盘写文件时，写一般的时候，如果进程崩了（操作系统还未崩溃），文件里面会有数据么？如果用的是带缓冲的写文件，文件里面是否有数据？（大概就是，进程写文件（使用缓冲 IO）过程中，写一半的时候，进程发生了崩溃，已写入的数据会丢失吗？）

答案：是不会的。

        因为进程在执行 write （使用缓冲 IO）系统调用的时候，实际上是将文件数据写到了内核的 page cache，它是文件系统中用于缓存文件数据的缓冲，所以即使进程崩溃了，文件数据还是保留在内核的 page cache，我们读数据的时候，也是从内核的 page cache 读取，因此还是依然读的进程崩溃前写入的数据。

        内核会找个合适的时机，将 page cache 中的数据持久化到磁盘。但是如果 page cache 里的文件数据，在持久化到磁盘化到磁盘之前，操作系统发生了崩溃，那这部分数据就会丢失了。

        当然， 我们也可以在程序里调用 fsync 函数，在写文文件的时候，立刻将文件数据持久化到磁盘，这样就可以解决系统崩溃导致的文件数据丢失的问题。

Q1：C语言的fwrite写了一段内存写到文件里面去，假设fwrite返回了，进程crash && 操作系统没宕机，数据会丢么？

A1：不会丢

Q2：先调用fwrite，之后调用fsync，之后操作系统宕机了，数据会丢么？

A2：在刷新数据到磁盘之前，如果操作系统崩了，数据会丢

Q3：先调用fwrite，之后调用fsync，之后操作系统宕机&&磁盘掉电了，数据会丢么？

A3：不会丢。fsync函数，会立即将pagecache中的数据刷写入磁盘

2.2.page cache是什么？

上图中，红色部分为 Page Cache。可见 Page Cache 的本质是由 Linux 内核管理的内存区域。我们通过 mmap 以及 buffered I/O 将文件读取到内存空间实际上都是读取到 Page Cache 中。

2.3.page和page cache

• page是内存管理分配的基本单位，在操作系统中通常为4KB大小
• page cache是由多个page构成，则为page的4KB整数倍

tip1：并不是所有 page 都被组织为 Page Cache

Linux 系统上供用户可访问的内存分为两个类型，即：

• File-backed pages：文件备份页也就是 Page Cache 中的 page，对应于磁盘上的若干数据块；对于这些页最大的问题是脏页回盘；
• Anonymous pages：匿名页不对应磁盘上的任何磁盘数据块，它们是进程的运行是内存空间（例如方法栈、局部变量表等属性）；

tip2：为什么 Linux 不把 Page Cache 称为 block cache，这不是更好吗？

答：因为从磁盘中加载到内存的数据不仅仅放在 Page Cache 中，还放在 buffer cache 中。

2.4. Page Cache 与 buffer cache

执行 free 命令，注意到会有两列名为 buffers 和 cached，也有一行名为 “-/+ buffers/cache”。

~ free -m
             total       used       free     shared    buffers     cached
Mem:        128956      96440      32515          0       5368      39900
-/+ buffers/cache:      51172      77784
Swap:        16002          0      16001

cached 列表示当前的页缓存（Page Cache）占用量：page cache用于缓存文件的页数据

buffers 列表示当前的块缓存（buffer cache）占用量：buffer cache用户缓存块设备（如磁盘）的块数据

• 页是逻辑上的概念，因此 Page Cache 是与文件系统同级的
• 块是物理上的概念，因此 buffer cache 是与块设备驱动程序同级的

2.5.page cache适用场景

2.5.1.不适用于大文件传输

具有「局部性」，所以通常，刚被访问的数据在短时间内再次被访问的概率很高，于是可以用 PageCache 来缓存最近被访问的数据，当空间不足时淘汰最久未被访问的缓存。

所以，

1. 读磁盘数据的时候，优先在 PageCache 找，如果数据存在则可以直接返回；如果没有，则从磁盘中读取，然后缓存 PageCache 中。
2. 读取磁盘数据的时候，需要找到数据所在的位置，但是对于机械磁盘来说，就是通过磁头旋转到数据所在的扇区，再开始「顺序」读取数据，但是旋转磁头这个物理动作是非常耗时的，为了降低它的影响，PageCache 使用了「预读功能」。

这两个做法，将大大提高读写磁盘的性能。

        但是，在传输大文件（GB 级别的文件）的时候，PageCache 会不起作用，那就白白浪费 DMA 多做的一次数据拷贝，造成性能的降低，即使使用了 PageCache 的零拷贝也会损失性能

        这是因为如果你有很多 GB 级别文件需要传输，每当用户访问这些大文件的时候，内核就会把它们载入 PageCache 中，于是 PageCache 空间很快被这些大文件占满。

另外，由于文件太大，可能某些部分的文件数据被再次访问的概率比较低，这样就会带来 2 个问题：

• PageCache 由于长时间被大文件占据，其他「热点」的小文件可能就无法充分使用到 PageCache，于是这样磁盘读写的性能就会下降了；
• PageCache 中的大文件数据，由于没有享受到缓存带来的好处，但却耗费 DMA 多拷贝到 PageCache 一次；

所以，针对大文件的传输，不应该使用 PageCache，也就是说不应该使用零拷贝技术，因为可能由于 PageCache 被大文件占据，而导致「热点」小文件无法利用到 PageCache，这样在高并发的环境下，会带来严重的性能问题

2.5.2.大文件传输用什么方式实现？

        先来看看最初的例子，当调用 read 方法读取文件时，进程实际上会阻塞在 read 方法调用，因为要等待磁盘数据的返回，如下图：

具体过程：

• 当调用 read 方法时，会阻塞着，此时内核会向磁盘发起 I/O 请求，磁盘收到请求后，便会寻址，当磁盘数据准备好后，就会向内核发起 I/O 中断，告知内核磁盘数据已经准备好；
• 内核收到 I/O 中断后，就将数据从磁盘控制器缓冲区拷贝到 PageCache 里；
• 最后，内核再把 PageCache 中的数据拷贝到用户缓冲区，于是 read 调用就正常返回了。

对于阻塞的问题，可以用异步 I/O 来解决，它工作方式如下图：

        可以发现，异步 I/O 并没有涉及到 PageCache，所以使用异步 I/O 就意味着要绕开PageCache。

说明：绕开 PageCache 的 I/O 叫直接 I/O，使用 PageCache 的 I/O 则叫缓存 I/O。通常，对于磁盘，异步 I/O 只支持直接 I/O

于是，在高并发的场景下，针对大文件的传输的方式，应该使用「异步 I/O + 直接 I/O」来替代零拷贝技术。

直接 I/O 应用场景常见的两种：

• 应用程序已经实现了磁盘数据的缓存，那么可以不需要 PageCache 再次缓存，减少额外的性能损耗。在 MySQL 数据库中，可以通过参数设置开启直接 I/O，默认是不开启；
• 传输大文件的时候，由于大文件难以命中 PageCache 缓存，而且会占满 PageCache 导致「热点」文件无法充分利用缓存，从而增大了性能开销，因此，这时应该使用直接 I/O。

总结：传输文件的时候，要根据文件的大小来使用不同的方式：

• 传输大文件的时候，使用「异步 I/O + 直接 I/O」
• 传输小文件的时候，则使用「零拷贝技术」