企业官网建设流程全解析

文件管理这块，很多人在学校上课或自学的时候，都觉得是“背概念”，什么逻辑结构、物理结构、FAT表、索引节点，一个个名词背得滚瓜烂熟，一到实际排查问题或者做系统设计就傻眼。我在实际工作中遇到的不少同事，甚至包括一些工作两三年的研发，对文件系统怎么把数据落到磁盘上这件事，认知都停留在“反正有系统帮我管”的程度。直到某天线上日志文件删不掉、磁盘空间异常、或者写文件突然变慢，才想起来翻操作系统书。这个标题把“文件逻辑结构、物理结构、磁盘基础”串在一起，本质上是在回答一个核心问题：文件系统的设计者，是怎么在又快又省空间又要可靠这三者之间做权衡的。

这篇文章我就用实际工程里的视角，把这个知识链条拆开讲透，不光学完能应付面试，更重要的是你以后做存储、做数据库，或者只是单纯想搞明白“为什么我的磁盘碎片化这么严重”，都能用得上。

1. 文件管理整体思路：从用户视角到底层存储的映射

1.1 文件系统到底在解决什么问题

你先想一个最简单的问题：你写了一个文本文件，保存的时候它是一串字节流，比如“你好世界”这四个中文字符，如果你用UTF-8编码，它会占据12个字节。这个文件的文件名叫hello.txt，它在你的桌面目录下。就这么一个简单的东西，操作系统背后要干多少活？它要知道这个文件名对应哪些磁盘扇区，要知道文件从哪开始到哪结束，要知道文件创建时间、修改时间，还要知道哪块磁盘空间是空闲的可以被覆盖，以及哪些空间已经被占用不能碰。

这一整套的管理工作，就是文件系统。它之所以复杂，是因为它要在一个机械结构或者电子存储介质上，建立一个逻辑上方便人类使用的“目录树—文件”模型。文件管理这个模块，在操作系统里面其实是承上启下的一个层次：上面要接系统调用接口，让用户程序可以open、read、write、close；下面要对磁盘设备驱动屏蔽物理细节。

在实际的设计中，有三个核心问题始终贯穿：

• 怎么组织文件中数据的顺序，让用户感觉它是一个连续的字节流；
• 怎么将文件中逻辑上连续的字节映射到物理上可能不连续的磁盘块；
• 怎么高效管理磁盘这个慢速设备，减少机械寻道带来的性能损失。

这三个问题，正好就对应了标题里的“逻辑结构—物理结构—磁盘基础”。

1.2 为什么逻辑结构和物理结构要分开看

这是很多初学者最容易混淆的一层。逻辑结构描述的是“用户眼中”文件长什么样，而物理结构描述的是“磁盘眼中”文件怎么存放。搁到代码里面类比，逻辑结构就是接口Interface，物理结构就是具体的实现Impl。你向文件系统写入一段数据时，它先把这段数据放在页缓存（Page Cache）里，然后后续某个时间点再决定把它写入哪些具体的扇区。逻辑结构决定了读写的API语义，物理结构决定了实际IO的布局。

一个非常典型的例子是数据库的表文件。在逻辑结构上，MySQL的InnoDB把表数据组织成B+树，这是一种索引结构，但它背后的磁盘文件很大，物理上可能被切分成很多个区段（Extent），分散在磁盘的不同位置。如果物理结构设计得不好，导致随机IO过多，整个数据库的性能就会急剧下降。所以说，理解这两者的区别不仅是应付考试，更是后续做性能优化和故障排查的基础。

考虑到文件是磁盘上最核心的数据抽象，下面我就把这两层结构的具体形态和取舍拆开讲。

2. 文件逻辑结构：用户眼中的文件到底长什么样

2.1 无结构文件与定长记录文件

文件逻辑结构按最简单的分类，可以分为两类：无结构文件（流式文件）和有结构文件（记录式文件）。

无结构文件最常见，它就是一段字节流，没有内部结构，或者说不关心内部结构。比如各种文本文件、图片文件、可执行文件，系统只管给你一串字节，至于里面是文本还是图片编码，完全是应用层的事情。在这种文件上，操作系统提供的操作就是读某偏移地址的一段字节、写某偏移地址的一段字节。这也解释了为什么很多程序员觉得文件就是个“大数组”，你随机读写时，跟访问内存数组的感觉差不多。

有结构文件则是把文件内部划分成一条条逻辑记录，常见于早期的数据库、成绩单管理、账务系统等场景。这里又能细分成定长记录和变长记录。定长记录文件里每条记录的长度是固定的，比如你存一批学生的学号，每个学号固定8字节，那第n条记录的起始位置就能通过n × 8直接计算出来，这种文件的随机访问极其高效，本质上是数组。变长记录就麻烦一些，比如一个字段长度不定的JSON日志文件，你很难通过简单的公式直接定位第n行日志，一般就需要配合行索引或者附加的结构来辅助定位。

从实际应用来看，现在的操作系统文件系统，面上几乎都是无结构文件为核心，因为这种设计简洁、通用性最强。凡是需要内部结构、要索引、要记录分隔符的，都交给应用层去解析。这个哲学一直延续到今天：操作系统保持简单，复杂结构统统上浮到应用层。

2.2 顺序访问、随机访问与操作接口的差异

逻辑结构的划分，又决定了这个文件支持的访问模式。顺序访问就是老老实实从头到尾读，或者从当前位置继续读；随机访问就是在文件里跳着读，先读到第500K位置，再回去读第100K位置。

对无结构文件来说，随机访问的实现方式就是修改文件读写的偏移量。在Linux里，你可以用lseek这个系统调用，把文件偏移指针移动到指定位置，然后再调用read或者write，这就完成了随机访问。

对有结构的定长记录文件，随机访问更是小菜一碟，直接算偏移就行。真正的痛点在于变长记录文件上的随机访问。举个例子，一个2GB的文本日志文件，每行长短差异很大，你想直接读最后100行，如果不是先扫一遍整个文件拿到行索引，几乎没法精确跳转。实际工程里常见的方案，就是给这类文件额外配一个稀疏的偏移索引，或者干脆用专门的日志存储系统来管理。这说明一个道理：逻辑结构选型和上层应用的数据访问模式高度相关，决定一个组件的设计时不应只看“能存”，更要看“怎么读”。

顺着这个思路，文件内部结构梳理清楚了，接下来就得关心这些字节到底放到磁盘哪里，这就是物理结构登场的时刻。

3. 文件物理结构：数据到底存放在磁盘哪里，又是怎么被找到的

3.1 连续分配、链接分配与索引分配：三种方案的经典取舍

物理结构最核心的问题，是把逻辑上的连续字节流，映射到磁盘上的物理块集合。常用的方案有三种，各有各的适用场景和致命伤。

连续分配是“最理想但不现实”的方案。它在磁盘上找一块连续的空闲区域，把文件的全部数据块放在里面，文件目录项只需要记录“起始块号 + 长度”就够了。优点是简单粗暴，随机访问极其高效，因为只需一次寻道就能把整个文件区域扫出来；缺点也极其致命——文件没法动态增长，你在中间插入数据基本上不可能，而且长时间使用后磁盘碎片化会越来越严重。这就是为什么现代通用文件系统基本不采用纯粹的连续分配。但有些场景还是会借鉴它，比如光盘上的ISO9660文件系统，文件本来就是刻录之后不变的，连续分配很合适。

链接分配是“解决碎片化但牺牲随机访问”的方案。它给每个文件数据块都留一个指针，指向下一块。FAT文件系统就是这类结构的代表，它用一个单独的区域（File Allocation Table）保存所有块的链接信息，目录项只记录文件的第一块，后续块就顺着表查下去。优点是文件可以任意增长，磁盘碎片也可以被使用，缺点是随机访问慢——你要读第1000个块，就不得不从第一块开始顺着链子走1000步。这种方案在早期软盘时代算是黄金方案，因为那时候磁盘容量小，文件小，顺序访问是绝对主流。但放到今天，动不动几个GB的文件，这种结构就力不从心了。

索引分配是当前主流文件系统的正解，它在文件创建时分配一个索引块，里面存放这个文件所有数据块的块号数组，类似于给文件做一个“块号清单”。拿数组类比的话，连续分配是“连续数组”，链式分配是“链表”，索引分配是“指针数组”。这样随机访问就快多了：要读第n块，直接查索引块中第n个表项，定位到物理块号就可以发起读取。缺点是每个文件要额外消耗一个索引块，而且还存在一个“大文件索引块不够用”的问题。

所以大文件怎么处理？经典的演进方案就是多级索引和混合索引。多级索引就是索引块里放的不是数据块号，而是下一级索引块的块号。混合索引则是把几种方式混合起来用，比如文件的前12个数据块号直接放在inode里，直接寻址，超过12块之后再用一级间接索引，如果还更大，再用二级间接索引。这就是Unix System V inode的经典设计。

为了让你直观感受这个设计的巧妙，我拿一个小例子算一下：假设文件系统块大小是1KB，块号占4字节，那一个索引块可以存放256个块号。一个inode里先放12个直接块指针，那文件能直接管理12KB；一级间接索引指向一个索引块，这个索引块又可以指向256个数据块，也就是256KB；二级间接索引则能管理256 × 256 = 65536个数据块，也就是64MB。三级索引再往上就是16GB的量级。这种阶梯式的结构，对小文件开销极小，对大文件又能支持超大容量，怪不得能成为几十年不衰的经典方案。

3.2 现代文件系统在物理结构上的演进：Ext4的Extent与B+树

经典的索引分配有一个现实的浪费问题：如果一个文件的数据块是连续的（磁盘分配时正好找到了一段连续空间），使用索引块依旧需要一个指针一个指针地记录，占用了好多额外存储，这不符合实际场景里的空间效率。

所以现代文件系统纷纷改用了“区段（Extent）”的概念。Ext4里就用extent树替换了传统的直接/间接块映射。所谓extent，就是一段连续的磁盘块序列，描述为一个起点块号 + 长度。对一个几十MB的连续文件，可能只需要很少的几个extent条目就够了，而不像索引分配那么烦琐地要求逐块记录。这就把“索引分配支持随机访问”和“连续分配节省元数据”的优势结合在一起了。

XFS则更激进，它的数据块寻址用的是一个B+树结构，专门用于管理文件物理块的映射。B+树天生支持高效的查找、插入和删除，对付大文件时的性能远胜传统的多级索引。为什么数据库和文件系统最终都走向B+树，核心原因就是它把随机点查询和高效区间扫描统一到了一个结构里，还能通过调整节点大小适配磁盘IO特性。你在看分布式存储系统比如某个开源对象存储时，也能看到它们对逻辑块到物理块映射用B+树或类似结构的影子。这算是一个规律级的现象。

3.3 物理结构里的核心配角：目录项与空闲空间管理

文件的物理位置记录是一方面，另一个同等重要的是目录和空闲空间管理。目录项（dentry或dir_entry）负责把文件名和inode号关联起来。一个目录其实就是一个特殊文件，里面存放着一个个目录项，每个目录项包含文件名、inode号、文件类型等信息。

目录项的存储方式也对文件系统性能有决定性影响。老式的FAT文件系统，目录就是个线性表，你要查找某文件就得从头到尾线性扫描，文件一多就慢得离谱。而ext4通过使用目录项树（Htree索引）优化了大目录下文件名查找的性能，大目录里创建、删除、查找一个文件都接近常数级。

空闲空间管理同样分策略。最传统的做法是位图（bitmap），拿一块内存或磁盘区域，每一位对应一个数据块，0表示空闲，1表示占用。这个方法的优点是查找和更新速度都极快（一次位操作就能判断），缺点是位图本身可能很大，而且为避免频繁写入导致性能瓶颈，文件系统往往会把它缓存在内存中。

相对地，有些文件系统也用空闲链表或B+树管理空闲区域，各有优劣。但这块性能好坏直接表现到“往磁盘写一个大文件”时的分配速度，所以也有一些现代文件系统的分配器做了优化，例如尽量为文件分配连续空间以减少碎片化。

物理结构听完，你肯定已经意识到：文件系统的很多设计选择都是因为磁盘的物理特性使然，所以要真正理解为什么文件系统长这样，还得蹲下来看看磁盘本身。

4. 磁盘基础：机械硬盘的物理特性与性能约束

4.1 盘面、磁道、扇区与柱面：磁盘到底是怎么组织数据的

磁盘由盘片、磁头、主轴电机、磁臂等核心部件组成。盘片上下两面各有一个磁头，数据就记录在盘面上的同心圆环中，这些圆环叫磁道。每个磁道又被划分成若干个扇区，传统上扇区大小是512字节，现在大容量机械硬盘基本都转用4K扇区（先进格式化技术）。

从物理地址看，磁盘上一个具体的数据块位于哪个扇区，需要用“柱面号—磁头号—扇区号”这个三元组来定位。柱面就是指所有盘面上同一半径磁道的集合，因为它对应的所有磁道可以被同一个磁头位置访问，所以访问柱面意味着无需移动磁臂。读取数据时，磁头必须先移动到目标磁道上方——这是寻道操作，然后等待盘片旋转，让目标扇区转到磁头下——这是旋转定位操作，随后才能开始读写——这是传输操作。

这三个操作的时间特性差异非常大。寻道时间通常是几毫秒到十几毫秒，旋转延迟平均是磁盘旋转半圈的时间，按7200转/分钟算的话，一转是8.33毫秒，半圈大概4.17毫秒。而传输时间相对要小得多，读一个4KB的块在顺序场景下几乎可以忽略。所以你实际观察到的磁盘读写性能，绝大部分都消耗在寻道和旋转等待上，这也是为什么随机IO性能远低于顺序IO。

4.2 一块普通的机械盘在真实IO负载下表现得有多“慢”

我先给你一个感性的认识。某个普通7.2K RPM企业级机械硬盘，顺序读带宽大概150MB/s左右，顺序写可能也在120~150MB/s；但一旦变成随机4K读写，每秒只能完成大概100~200次IO操作，换算成带宽只有0.4~0.8MB/s，差距是百倍级别。

你可能会疑惑：一块硬盘的物理介质本身是同一个盘片，同样的转速，为什么随机和顺序差距能拉这么大呢？核心就在于磁头寻道的物理代价。顺序读写时，磁头可以连续地从一条磁道过渡到下一条相邻磁道，大多数情况下几乎不需要大幅寻道，甚至可以通过预读把后续可能访问的数据也搬进缓存，效率自然高。而随机读写时，每换一个数据块都要让磁头跑来跑去，先移动，再等盘片转，时间都耗在“路程”上。

这也是为什么数据库、消息队列、日志系统这些底层存储都强调“顺序写”的原因之一。很多号称性能很强的存储引擎，本质上是把用户的随机写操作“假装成”顺序写落盘，比如有些KV存储和日志格式的存储都用append-only的设计，把更新的数据作为新记录追加到文件末尾，再用后台机制做合并整理，正是吃透了磁盘顺序访问这个特性。

4.3 磁盘调度算法：操作系统是怎么排队处理IO的

磁盘IO请求并不总是单个出现，更多时候是多个进程同时在发请求。如果OS像一个老实的办事员，来一个处理一个，那磁头会在磁盘上各处乱窜，效率低下。于是操作系统实现了磁盘调度算法，对IO请求队列里的若干请求进行重排。

先有先来先服务（FCFS），这是最公平也最愚蠢的方案，完全不管寻道距离，会被随机负载打到性能谷底。然后是最短寻道时间优先（SSTF），它总是选择离当前磁头位置最近的请求，能显著降低平均寻道时间，但缺点是低优先级的远端请求可能长期得不到服务，产生“饥饿”。

再往后是SCAN算法（电梯算法），磁头从一端开始向另一端移动，途中服务所有经过磁道的请求，到头后反向再扫回来，就像电梯一样，上下各一次。这个算法解决了饥饿问题，而且磁头移动模式比较规律。C-SCAN只在一个方向服务，返回时直接跳到另一端，这样对所有磁道的响应更均匀，还有SPTF等基于扇区最优的更细粒度调度变体。

在实际操作系统中，现代的Linux内核在块层用的是基于deadline或mq-deadline的调度算法，在保证吞吐量的同时注意把迟到的、快要超时的请求优先处理，并倾向于合并合并相邻的IO请求，形成顺序请求模式。理解了这些调度机制，你就能明白为什么同一个服务器规格，数据库跑得好不好，OS挂载参数和调度器选型的影响竟会那么大。

4.4 固态硬盘和机械硬盘在文件系统设计上的根本差异

SSD没有机械寻道，随机读写速度远超机械盘，但引入了新的问题：擦除界限（块是写入擦除的基本单位，但操作粒度不对称）和写放大。如果一个文件系统针对机械盘设计，每次写小数据块都去修改原位置，在SSD上就会导致频繁擦块、写放大，加速磨损。

再叠加一个更常见的现代制约：即在随机写入写入量大的场景，文件系统层的机制可能成为限制因素。现代SSD主控内部有自己的FTL层，这个FTL负责把上层文件系统的逻辑块地址映射到物理闪存页，它还包含磨损均衡、垃圾回收等机制。你从OS层面看到的块设备，其实已经是被SSD主控“包装”后的抽象视图。

所以，针对SSD的文件系统，尽量把写入进行追加式写入，让物理页尽量顺序写入，减少擦除周期，比如F2FS，其基本的思路就是采用Log-structured结构，把写入集中到连续区域，并配有额外的clean操作线程在后台进行垃圾回收。这就解释了为什么数据库或文件系统在SSD上的很多优化思路和机械盘时代不一样。传统上很多“高手教你优化磁盘”的招数，其实已经是过时的产物了。

5. 实操指导：在Linux环境下验证文件系统结构和磁盘特性

5.1 用stat、debugfs和filefrag解剖一个文件的物理布局

理论知识讲再多，不如在系统里亲手摸一遍。我在Linux服务器上经常用三个命令来观察文件系统的运行状态，正好对应我们前面讲的三层结构。

stat命令是第一步，它直接列出文件inode里的核心元数据。比如你执行stat hello.txt，能看到文件大小、块数、IO块大小、inode号、权限、时间戳。注意里面的Blocks字段，它表示文件占用了多少个512字节扇区，而IO Block通常显示4096，表明文件系统逻辑块大小是4KB。如果文件是稀疏文件，你还能通过这个字段发现文件实际占用的块数远小于按大小换算出的块数。

第二步是用filefrag来查看文件的物理碎片情况。比如filefrag -v hello.txt，它会列出这个文件在磁盘上被分配成了几个extent，每个extent的物理起始块号和长度。如果文件是刚创建且连续写入的，你可能只看到1个extent；如果文件经历过大量随机写入和删除后再写，就可能有几十个extent。这个命令是观察物理结构的利器，也是验证“顺序写入产生连续分配”的最好手段。

第三步是更底层的debugfs，对于扩展文件系统，可以用它直接查看inode的内容和块寻址结构。比如使用debugfs -R "stat <inode号>" /dev/sdX，它会把inode的相关信息以及直接块、间接块等字段都打印出来。你可以根据自己的环境试试，把一个大文件和一个几百字节的小文件对比看，能明显看到小文件直接使用inode里预分配的直接块指针，而大文件则进入了extent树或者间接索引的领地。

这三步操作下来，你在书本上学的“inode存元数据”“extent映射物理块”这些概念，就变成活生生的可观察、可验证的行为。有了这些基础，你再去看别人分析文件系统性能问题的文章，理解起来就完全不在一个层级了。

5.2 通过创建文件系统、观察碎片化、对比调度器效果来直观感受磁盘基础

除了看，还可以动手做一个验证方案。我在给一些朋友做培训时，经常用一个非常直观的对比实验来展示文件系统分配策略和磁盘IO特性的重要性。

准备一块独立的磁盘或一个loop设备，先格式化成ext4，挂载后用一条脚本创建500个小文件，每个4KB大小，反复几次：先创建、再删除其中一半、再填充新文件。整个过程结束后，用filefrag看新文件的extent数量，你会发现碎片化现象很普遍。然后换一个场景：一次性顺序写一个1GB的大文件，再查看它的extent数量，大概率是很少的连续段。这两个场景对比，能让你一眼看出文件系统在分配策略上的倾向性和碎片产生的来源。

衡量磁盘IO性能也很方便，Linux自带fio工具。可以用fio分别测顺序读、顺序写、随机读、随机写四种模式下的IOPS和带宽，几行配置就能跑完，比如：

• fio --name=seqread --rw=read --bs=1M --size=1G --numjobs=1 --runtime=30 --group_reporting
• fio --name=randread --rw=randread --bs=4K --size=1G --numjobs=4 --runtime=30 --group_reporting

这样测出来的数据差异会非常直观，基本都是数量级的差别。你还可以顺手把调度器切成none或者mq-deadline再测一轮，看看对随机IO的影响，就明白调度器在真实系统中的意义了。

5.3 这些知识在系统设计中的实际应用：日志落盘、数据库文件、容器镜像

理解了文件系统的这三根支柱，你在日常研发中看很多技术方案都会豁然开朗。

日志系统是顺序IO的典型受益者。像Kafka这种消息系统，所有消息都追加到日志分段文件的末尾，消费时也是顺序读为主，天然契合磁盘顺序读写的优势。如果换成随机写小消息，性能就惨不忍睹。MySQL的redo log也是同样的道理，它在崩溃恢复时为了保证性能和可靠性，一定要求顺序写足够快。

数据库数据文件的设计则巧妙地同时利用了两类IO特性。一个事务提交时的关键信息用日志顺序写保证低延迟，而实际数据页的落盘则在后台随机写，配合组提交、双写缓冲这些机制，尽量减小随机IO对系统的影响。一般数据库的调优，很大一部分都是围绕“减少随机IO、提高顺序IO比例”在进行。

容器镜像的分层存储也是文件系统物理结构的典型应用。容器镜像的每一层在宿主机上是多个目录下的文件，底层是overlayfs实现的联合挂载。不同层的文件在文件系统物理块上可能完全分散，所以运行多个容器时，页缓存命中率、磁盘IO模式都可能受影响。这些细节在你做大规模容器化部署时，就会变成实实在在的性能瓶颈。

看完了应用场景和实验，最后我把从这些实操和排查中沉淀出来的经验做个小结，应该能帮你少走不少弯路。

6. 常见问题与排查技巧实录

6.1 实战排查日记：大表查询突然变慢的定位过程

有一次线上数据库实例的某个大表在查询时突然延迟飙升，业务方反馈“全表扫描特别慢”。第一个直觉是慢SQL，但看了执行计划发现索引没问题。后来我用iostat -x 1观察磁盘，发现这块盘的%util一直在90%以上且await高到离谱，而随机读IOPS却没多大变化。

再用debugfs配合filefrag查看那个表空间文件，发现它被切成了几百个extent，且分散在整个磁盘上。进一步排查才知道，原来是之前有同事做了一次批量删除和重建分区，又开了自动扩展，表空间文件在多次伸缩后碎成了一地。方案很直接：用mysqldump导出再导入重建表空间，或者在线做一次表空间重组，finally之后查询延迟恢复正常，磁盘的await也掉下来了。这个案例里，物理结构的知识是定位根因的核心钥匙。

还有一次，某服务日志目录里有很多小文件，发现清理脚本跑完以后服务还在反复创建和删除文件，导致磁盘IO升高。实际上这就是典型的空闲块分配抖动，因为文件系统要反复分配和释放零散的小块，导致元数据操作频繁。后来我们把固定周期的日志清理改成了分批、小批量、低频清理，效果立竿见影。

6.2 常见问题速查表：高频疑问与排查要点

我把实践里被问得最多的问题整理成了一个表格，照着查能节省不少时间。

这些排查思路，本质都是从“逻辑层下探到物理层”的过程，你可以顺着表格自己动手实践一番。

6.3 实用避坑技巧与调参心得：从挂载参数到文件系统选型

最后分享几个我在不同操作系统环境里实践出来、比较有价值的调优/避坑要点。

第一个是挂载参数。文件系统在挂载时有很多可以优化的选项。比如对很多日志型场景，可以在mount时加noatime，免去每次读文件都更新访问时间戳的开销；对追求可靠性优先的场景，则要合理设置commit值，控制元数据多久刷一次盘。有时候一个看似微小的挂载参数，在高频IO场景里引起的性能差距可以达到两位数百分比。

第二个是块大小选型。创建文件系统时，块大小是个需要权衡的参数。4K块适合大量小文件的通用场景，能减少内部碎片；如果你确定存的基本都是大文件，比如视频文件、数据库的备份文件，则可以把块大小调到更大。但注意块大小是格式化时确定的，后期改起来非常麻烦，所以一定要在建文件系统前想清楚业务的文件大小分布。

第三个是对SSD和机械盘要有不同的文件系统选型态度。如果是纯机械盘环境，采用顺序写友好的应用设计比什么玄学调优都重要；而在SSD上，关注写放大和磨损，尽量选用支持TRIM/丢弃操作的文件系统挂载选项，定期让系统执行fstrim——这是纯粹的SSD时代产物。很多年来人们从机械盘时代带过来的“碎片整理”习惯，在SSD上是反效果的。

这些坑和技巧，都是我在真实生产环境里一步步踩出来的。有些问题书本上不一定会写，但是性能和稳定性问题基本都出在这些容易被忽略的细节上。

关于文件系统的知识，我最后还想强调一点实际体会：你在学校学操作系统时，可能觉得逻辑结构、物理结构、磁盘调度这些都是孤立的考点，但真正到了工程里，它们始终是相互牵扯的一整个系统，任何一个设计都没有绝对的好坏，只有面向具体业务负载的取舍。想到某个存储引擎要把随机写变成顺序写，想到某个文件系统要用B+树管理extent，你能从磁盘的物理特性出发推导出它的设计动机，这些东西才算真正内化成了你自己的判断力。多拿几块盘、多格式化几个文件系统、多跑几次fio，在这些实际操作中形成的体感，比死记背书里的图有用得多。