文件系统实现方法与分布式文件系统
摘要 文件系统是操作系统设计环节中至关重要的一环，本文分析文件系统的整体架构，通过对几个常见的文件系统来深入剖析文件系统的发展趋势，同时对前沿的分布式文件系统进行分析。
关键词 文件系统、Ucore、xv6、分布式
引言
文件系统的目的是组织和存储数据,典型的文件系统支持用户和程序间的数据共享,并提供数据持久化的支持。文件系统是操作系统设计环节中至关重要的一环，文件系统的实现方法非常多，文件系统也在随着时代的发展而发展。分布式文件系统是当前文件系统研究的核心，本文会结合Ucore和xv6文件系统的设计来区分分布式文件系统和普通文件系统在设计上的差异。
### Ucore文件系统
我们先通过分析Ucore操作系统的文件系统，来分析文件系统的整体架构。
概述
| 通用文件系统访问接口 |
|---|
| 文件系统抽象层 VFS |
| SImple FS文件系统 |
| IO设备访问层 |
Ucore的文件系统设计分为四层。IO设备访问层进行对磁盘的读写操作，SimpleFS建立了一个简单的文件系统，而在SimpleFS上抽象了一个VFS文件系统抽象层，设计了一套更加抽象统一的文件系统操作，最后用户通过系统调用，调用通用文件系统访问接口实现我们的文件系统操作
Ucore文件系统主要包含四类主要的数据结构，在后面几个文件系统中，这几类数据结构会经常反复地出现：
- 超级块（SuperBlock），它主要从文件系统的全局角度描述特定文件系统的全局信息。它的作用范围是整个OS空间。
- 索引节点（inode）：它主要从文件系统的单个文件的角度它描述了文件的各种属性和数据所在位置。它的作用范围是整个OS空间。
- 目录项（dentry）：它主要从文件系统的文件路径的角度描述了文件路径中的特定目录。它的作用范围是整个OS空间。
- 文件（file），它主要从进程的角度描述了一个进程在访问文件时需要了解的文件标识，文件读写的位置，文件引用情况等信息。它的作用范围是某一具体进程。
在磁盘区域的划分上，Ucore的划分如下：
| superblock,存储文件系统的元信息（一个块） |
|---|
| Root-dir inode，用来记录根目录的相关信息（一个块） |
| 记录块占用情况的bitmap |
| 存储Inode和数据块 |
Inode设计
Ucore的SFS层定义了在硬盘上的Inode格式：
struct sfs_disk_inode {
uint32_t size; // 如果inode表示常规文件，则size是文件大小
uint16_t type; // inode的文件类型
uint16_t nlinks; // 此inode的硬链接数
uint32_t blocks; // 此inode的数据块数的个数
uint32_t direct[SFS_NDIRECT]; // 此inode的直接数据块索引值（有SFS_NDIRECT个）
uint32_t indirect; // 此inode的一级间接数据块索引值
};
在Ucore操作系统中，文件系统通过块的方式来组织。一个块的大小为4KB（相当于8个扇区的大小，内存一个Page的大小）。默认的，ucore 里 SFS_NDIRECT 是 12。在Ucore中一个Inode可以索引的文件大小最大为直接索引的48KB和间接索引的4MB。
Inode也可以指向一个目录，在这种情况下，目录块由以下数据结构的集合组成：
/* file entry (on disk) */
struct sfs_disk_entry {
uint32_t ino; // 索引节点所占数据块索引值
char name[SFS_MAX_FNAME_LEN + 1]; // 文件名
};
xv6文件系统
概述
| 系统调用接口层 |
|---|
| 文件路径递归查找 |
| 包含目录项的inode |
| 无名文件（inode和一连串数据块） |
| 会话层（磁盘更新会话打包） |
| 块缓存读写IDE硬盘 |
xv6文件系统从设计上分为6层（如上表所示）。最下面一层通过块缓冲读写IDE 硬盘,它同步了对磁盘的访问,保证同时只有一个内核进程可以修改磁盘块。第二层使得更高层的接口可以将对磁盘的更新按会话打包,通过会话的方式来保证这些操作是原子操作(要么都被应用,要么都不被应用)。第三层提供无名文件,每一个这样的文件由一个 inode和一连串的数据块组成。第四层将目录实现为一种特殊的inode,它的内容是一连串的目录项,每一个目录项包含一个文件名和对应的 inode。第五层提供了层次路经名(如/usr/rtm/xv6/fs.c这样的),这一层通过递归的方式来查询路径对应的文件。最后一层将许多UNIX 的资源(如管道,设备,文件等)抽象为文件系统的接口,极大地简化了程序员的工作。
在磁盘区域的划分上，XV6文件系统划分如下：
| boot引导区域 |
|---|
| superblock，存储文件系统的元信息 |
| inodes |
| bitmap记录空闲块的区域 |
| data数据块 |
| log日志块（会话层） |
xv6文件系统磁盘区域划分和Ucore有一些不同之处：
- 多了一个boot区域，这个区域是用来引导用的。为什么Ucore的文件系统磁盘架构中没有这个boot区域呢？Ucore把boot区域放在了另一个磁盘，而文件系统则放在了不同的磁盘，因此Ucore的文件系统中并没有划分出区分出boot区域。
- inodes和data数据块分开在不同的区域实现。由于这种区分，xv6不需要像Ucore一样
- 增加了一个日志系统，这是Ucore操作系统没有的，我们接下来会对日志系统的实现进行进一步的分析。
日志系统
文件系统设计中最有趣的问题之一就是错误恢复,产生这样的问题是因为大多数的文件系统都涉及到对磁盘多次的写操作,如果在写操作的过程当中系统崩溃了,就会使得磁盘上的文件系统处于不一致的状态中。
在数据库中，一种保持数据一致性的方式就是采取日志系统。文件系统的日志系统也是如此。在文件系统操作发生崩溃的时候，如果崩溃发生在操作提交之前,那么磁盘上的日志文件就不会被标记为已完成,恢复系统的代码就会忽视它,磁盘的状态正如这个操作从未执行过一样。如果是在操作提交之后崩溃的,恢复程序会重演所有的写操作,可能会重复之前已经进行了的对磁盘文件系统的写操作。在任何一种情况下,日志文件都使得磁盘操作对于系统崩溃来说是原子操作:在恢复之后,要么所有的写操作都完成了,要么一个写操作都没有完成。这种技术在数据库系统中也有涉及，称为checkpoint技术。
日志系统通过xv6文件系统的会话层实现，在磁盘区域划分上属于磁盘最后一个区域。
总结
从前面对Ucore和xv6文件系统的分析，我们可以总结文件系统由以下几个重要问题要解决：
- 文件系统的整体元信息（Superblock）
- 文件系统索引（Inode）
- 块使用与否的标记
- 文件系统路径查找
- 文件的读写操作
- 数据备份与恢复（日志）
下面对分布式文件系统的分析我们会结合上面几点来考虑。
分布式文件系统GFS
概述
2003年，谷歌为了应付越来越大的文件存储需求，提出了分布式文件系统GFS（Google File System）。HDFS等分布式文件系统在设计上都对GFS有所参考。
GFS包括一个master结点（元数据服务器），多个chunkserver（数据服务器）和多个client（运行各种应用的客户端）。
- **chunkserver提供存储，相当于Ucore和xv6存储数据块的磁盘区域。**数据块以普通Linux文件的形式存储在chunkserver上，出于可靠性考虑，每个数据块会存储多个副本，分布在不同chunkserver。
- GFS master就是GFS的元数据服务器，负责维护文件系统的元数据（相当于Superblock）、命名空间（相当于文件路径）、访问控制、文件-块映射（相当于Inode索引）、块地址等，以及控制系统级活动，如垃圾回收、负载均衡等。
- 应用需要链接client的代码，然后client作为代理与master和chunkserver交互。master会定期与chunkserver交流（心跳），以获取chunkserver的状态并发送指令。
GFS将文件条带化，按照类似RAID0的形式（如上图所示）进行存储，可以提高聚合带宽。GFS将文件按固定长度切分为数据块（每个块的大小达到64MB）。每个数据块以linux文件的形式存储在chunkserver的本地文件系统里。
另外，为了提高数据的可靠性和并发性，每一个数据块都有多个副本。当客户端请求一个数据块时，master会将所有副本的地址都通知客户端，客户端再择优（距离最短等）选择一个副本。
可靠性保证
分布式系统设计中，整体的可靠性是至关重要的。在集群众多的机器之中，往往存在几台机器发生故障。如何保证这几太机器的故障不会导致系统整体崩溃是分布式文件系统设计的重要问题。
- 数据完整性：GFS使用数以千计的磁盘，磁盘出错导致数据被破坏时有发生，我们可以用其它副本来恢复数据，但首先必须能检测出错误。chunksever会使用校验和来检测错误数据。每一个块（chunk）都被划分为64KB的单元（block），每个block对应一个32位的校验和。校验和与数据分开存储，内存有一份，然后以日志的形式在磁盘备一份。
- 数据一致性：指的是master的元数据和chunkserver的数据是否一致，多个数据块副本之间是否一致，多个客户端看到的数据是否一致。
- 可用性：GFS中master服务器只有一个，该服务器承担了巨大的压力，不仅存在性能上的问题，如何快速从故障中恢复master服务器也是需要考虑的点。GFS采用了采用了日志技术和checkpoint技术保证了Master节点数据的快速恢复。
参考文献
- 《The Google File System》 Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung @Google
- 《Xv6中文文档》
561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
