螺蛳壳里做道场：实现一个256KB的迷你文件系统
内容提要
本文介绍了一个基于小硬盘空间的极简文件系统的设计，包括数据区、元信息区和分配结构。文件系统的读写流程涉及到根目录的遍历、inode的读取和数据块的访问。文件的写入需要分配新的数据块，并进行相应的IO操作。文章总结了文件系统设计的基本理念和一些优化点。
延伸解读
从布局反推设计：为什么数据区是56块？
文章以64块、每块4KB的迷你硬盘为例，最终数据区占56块，inode区5块，位图2块，超级块1块。这个分配并非随意，而是根据元信息与数据的比例估算得出。读者可以从中理解文件系统布局的权衡：元信息占用过多会浪费空间，过少则限制文件数量。这种从后往前布局的思路，也体现了超级块放在最前以便挂载时快速读取的设计。
inode混合索引：小文件优先的实践智慧
文章指出大多数文件系统中，小文件占多数，因此inode采用12个直接指针加1个间接指针的混合方式。小文件直接通过直接指针访问数据块，避免额外IO；大文件才使用间接指针，并在数据区分配指针块。这种设计平衡了存储效率与访问速度。读者可以借此理解，文件系统的数据结构往往针对实际负载特征进行优化，而非追求理论上的统一。
读写路径的IO代价：写操作为何更复杂
读文件时，从根目录遍历到目标inode，再读取数据块，全程不涉及位图。而写文件需要分配新数据块，至少涉及五次IO：读位图、写位图、读inode、写inode、写数据。创建新文件则更多，还需操作inode位图和父目录。这解释了为什么写操作通常比读操作慢，也引出了缓存和缓冲的必要性。读者可以从中体会文件系统性能优化的关键点。
缓存与缓冲：性能提升背后的数据丢失风险
文章提到，为了减少IO，现代文件系统使用统一页面缓存和写缓冲，延迟刷盘。这能合并多次修改、提高带宽利用率，甚至省去无效写。但代价是意外宕机可能丢失数据。因此，文件系统提供direct I/O和fsync()让敏感应用绕过缓存或强制刷盘。读者应认识到，性能与持久性之间存在权衡，需根据应用场景选择合适策略。
Q&A
这个256KB迷你文件系统的磁盘布局是怎样的？
磁盘总大小为256KB，块大小4KB，共64个块。布局从后往前：数据区占56个块，inode区占5个块，数据位图和inode位图各占1个块，超级块占1个块。
inode在文件系统中起什么作用？它包含哪些信息？
inode（索引节点）用于保存文件的元信息，如文件名、大小、权限、时间戳等，并包含数据块索引（直接指针和间接指针），用于定位文件数据。
读取文件时，文件系统是如何从路径找到文件数据的？
从根目录的inode开始，逐级遍历路径中的每个目录，读取目录数据块找到下一级inode，直到找到目标文件的inode，然后根据inode中的数据块指针读取文件数据。
写入一个已存在的文件需要哪些IO操作？
至少需要五次IO：读取data bitmap、写回data bitmap、读取inode、写回inode、在空闲块中写入数据。
文件系统如何管理空闲空间？
使用两个位图（bitmap）分别管理数据块和inode的空闲状态，每个位对应一个块或inode，0表示空闲，1表示已用。
缓存和缓冲技术如何提升文件系统性能？
通过将频繁访问的数据块缓存在内存中，减少磁盘IO；写缓冲延迟刷盘，合并多次修改，提高IO效率，但可能增加数据丢失风险。
