分布式系统 Distributed Systems 第 11 讲 分布式文件系统 Lecture 11 Distributed File Systems 王晓阳、张 奇 复旦大学 计算机科学技术学院

目录 11.1 简介 11.4 Andrew文件系统 11.5 Google File System 11.2 文件服务体系结构 11.1 简介 11.1.1 文件系统特点 11.1.2 Linux文件系统 11.1.3 分布式文件系统需求 11.2 文件服务体系结构 11.3 SUN网络文件系统 11.4 Andrew文件系统 11.4.1 实现 11.4.2 缓存的一致性 11.4.3 其他 11.5 Google File System 11.6 小结

11.1 简介 资源共享是分布式系统一个重要特征 共享存储信息可能是分布式资源共享的一个重要方面 本章主要讨论基本分布式文件系统 11.1 简介 资源共享是分布式系统一个重要特征 共享存储信息可能是分布式资源共享的一个重要方面 Web服务器提供了一种严格的数据共享方式 局域网和企业内部网中的共享 为客户端提供各种类型的程序和数据的持久存储 本章主要讨论基本分布式文件系统 基本---- 分布式文件系统的主要目的是在多个远程计算机系统上模拟非 分布式文件系统的功能 不支持文件多持久副本，不提供带宽和实时保证

11.1 简介 文件系统是操作系统所提供的基础设施 企业内部网中，分布式文件系统以文件形式支持信息共享，以持久 存储的形式支持硬件资源共享 11.1 简介 文件系统是操作系统所提供的基础设施 磁盘存储程序的接口 访问控制 文件锁 企业内部网中，分布式文件系统以文件形式支持信息共享，以持久 存储的形式支持硬件资源共享

Overview/Review: Storage systems and their properties Sharing Persis- Distributed Consistency Example tence cache/replicas maintenance Main memory 1 RAM File system 1 UNIX file system Distributed file system Sun NFS Web server Web Distributed shared memory Ivy (DSM, Ch. 18) Remote objects (RMI/ORB) 1 CORBA Persistent object store 1 CORBA Persistent Object Service Peer-to-peer storage system 2 OceanStore (Ch. 10) Types of consistency: 1: strict one-copy. : slightly weaker guarantees. 2: considerably weaker guarantees.

Figure 12.3 File attribute record structure 11.1.1 文件系统的特点 文件系统 文件的组织、存储、检索、命名、共享和保护 提供描述文件抽象的程序接口 文件 数据和属性 目录 特殊的文件 访问控制 Figure 12.3 File attribute record structure

11.1.1 文件系统的特点 图12-2 文件系统模块

11.1.1 文件系统的特点 图12-2 UNIX文件系统操作 filedes = open(name, mode) filedes = creat(name, mode) Opens an existing file with the given name. Creates a new file with the given name. Both operations deliver a file descriptor referencing the open file. The mode is read, write or both. status = close(filedes) Closes the open file filedes. count = read(filedes, buffer, n) count = write(filedes, buffer, n) Transfers n bytes from the file referenced by filedes to buffer. Transfers n bytes to the file referenced by filedes from buffer. Both operations deliver the number of bytes actually transferred and advance the read-write pointer. pos = lseek(filedes, offset, whence) Moves the read-write pointer to offset (relative or absolute, depending on whence). status = unlink(name) Removes the file name from the directory structure. If the file has no other names, it is deleted. status = link(name1, name2) Adds a new name (name2) for a file (name1). status = stat(name, buffer) Gets the file attributes for file name into buffer. 图12-2 UNIX文件系统操作

11.1.2 Linux 文件系统 文件系统的最终目的是把大量数据有组织的放入持久性(persistant)的 存储设备中 自行设计开发的文件系统称为EXT2 Linux支持多种其它操作系统的文件系统： 如minix、ext2、hpfs、msdos、umsdos、iso、nfs、sysv、affs、ufs、efs等达二十几种。 虚拟文件系统VFS屏蔽了各种文件系统的差别，为处理各种不同文件系 统提供了统一的接口。

11.1.2 Linux 文件系统 最开始的区域是MBR， 用于Linux开机启动 剩余的空间可能分成 数个分区(partition) 每个分区有一个相关 的分区表(Partition table)，记录分区的相 关信息。 分区表是储存在分区 之外。分区表说明了 对应分区的起始位置 和分区的大小。

11.1.2 Linux 文件系统 Linux系统下也可以有多个分区，但都被挂载在同一个文件系统树上数 据被存入到某个分区中。 一个典型的Linux分区(partition)包含有下面各个部分: 启动区(Boot block) Linux开机启动后，会首先载入MBR，随后MBR从某个硬盘的启动区加载程序。该程序负责进一步的操作系统的加载和 启动。为了方便管理，即使某个分区中没有安装操作系统，Linux也会在该分区预留启动区。 超级区(Super block) 它存储有文件系统的相关信息，包括文件系统的类型，inode的数目，数据块的数目。 i-nodes 每个文件对应一个inode，其中包含多个指针，指向属于该文件各个数据块。

11.1.2 Linux 文件系统 i-node 保存文件的元数据(metadata)、数据块指针 数据块在1, 32, 0, ...

11.1.2 Linux 文件系统 在Linux中，通过解析路径，根据沿途的目录文件来找到某个文件。 目录中的条目除了所包含的文件名，还有对应的i-node编号。 输入$cat /var/test.txt Linux将在根目录文件中找到var这个目录文件的i-node编号 根据inode合成var的数据 根据var中的记录，找到text.txt的inode编号 沿着inode中的指针，收集数据块，合成text.txt的数据

11.1.2 Linux 文件系统

11.1.2 Linux 文件系统 注意： VFS并不是一种实际文件系统 EXT2等物理文件系统是存在于外存空间的，而VFS 仅存在于内存 VFS中包含着向物理文件系统转换的一系列数据结构，如VFS超级 块、VFS的i-node等、各种操作函数的转换入口。

11.1.3 分布式文件系统的需求 透明性 访问 位置 移动 性能 伸缩 客户程序不应了解文件的分布性 客户程序应使用单一的文件命名空间 文件移动时，客户程序和客户结点上的系统管理表都不必进行修改 性能 服务负载在一个特定范围内变化时，客户程序性能可以得到满意的性能 伸缩 文件服务可以不断扩充

11.1.3 分布式文件系统的需求 并发文件更新 文件复制 硬件和操作系统异构性 容错 一致性 安全性 效率

11.2 文件服务体系结构

11.2 文件服务体系结构 文件系统三个组成部分 平面文件服务器、目录服务器、客户端

11.2 文件服务体系结构 平面服务器 目录服务 实现文件内容操作 11.2 文件服务体系结构 平面服务器 实现文件内容操作 唯一文件标识符（UFID）：用于在所有平面文件服务器操作的请求中标 识文件 文件服务和目录服务的职责划分是基于UFID的使用 UFID在分布式文件系统中是唯一的 目录服务 提供文件名到UFID的映射 提供生成目录、为目录增加新文件名、从目录中获取UFID等功能

11.2 文件服务体系结构 客户模块 平面文件服务接口 运行于客户计算机上，在一个应用程序接口下集成和扩展平面文件服务 和目录服务的操作 11.2 文件服务体系结构 客户模块 运行于客户计算机上，在一个应用程序接口下集成和扩展平面文件服务 和目录服务的操作 提供给用户级程序使用与操作系统类似的接口 平面文件服务接口 客户模块使用的RPC

11.2 文件服务体系结构 平面文件服务接口 与UNIX比较 容错性差别 平面文件服务接口和UNIX的文件系统原语在功能上等价 11.2 文件服务体系结构 平面文件服务接口 与UNIX比较 平面文件服务接口和UNIX的文件系统原语在功能上等价 平面文件服务接口没有open和close操作 UNIX中没有平面文件服务接口中的Read和Write操作 容错性差别 可重复操作：除了Create之外，其余操作都是幂等价的 无状态服务器：不需要客户和服务器的任何状态

11.2 文件服务体系结构 访问控制 UNIX文件系统中，系统根据open中调用请求的访问模式(R/W)来检查用 户的访问权限 分布式实现 11.2 文件服务体系结构 访问控制 UNIX文件系统中，系统根据open中调用请求的访问模式(R/W)来检查用 户的访问权限 访问权限检查使用用户表示（UID） 非分布式实现中不能被修改，访问权限会保持到文件关闭为止 同一文件上进行的后续操作，系统不需进一步检查 分布式实现 访问权限检查必须在服务器上进行，用户标识须在请求中传输 如果访问权限检查的结果被保留在服务器上并在今后的访问中使用时，服务器不再是无状 态的 解决方法 文件名转换为UFID时，进行访问检查，结果以权能的形式编码 客户每次请求时都要提交用户标识，每次文件操作都进行访问检查

11.2 文件服务体系结构 目录服务接口 主要功能是提供文件名到UFID的转换

11.2 文件服务体系结构 层次文件系统 树形结构目录 每个目录包含文件和其他可以从此目录访问的目录的名字 11.2 文件服务体系结构 层次文件系统 树形结构目录 每个目录包含文件和其他可以从此目录访问的目录的名字 可以使用路径名来访问任一文件或目录 NOTE: UNIX 文件系统不完全是树形的---一个文件可以可以在一个或多个目录中有多个名字

11.2 文件服务体系结构 文件组 文件组是一个位于给定服务器上的文件集合 一个服务器可以包含数个文件组，文件组可以在服务器之间移动 11.2 文件服务体系结构 文件组 文件组是一个位于给定服务器上的文件集合 一个服务器可以包含数个文件组，文件组可以在服务器之间移动 与UNIX中filesystem（文件集系统），一个存储设备或者分区拥有的文件 的集合类似 分布式系统中文件组标识必须唯一 例如：创建文件组时可以使用： IP地址 日期 32位 16位 文件组标识： NOTE: IP地址不能用来定位文件

11.3 实例研究：SUN网络文件系统

11.3 SUN网络文件系统 Making remote files as if local to the client

i-node generation number 11.3 SUN网络文件系统 虚拟文件系统（VFS） NFS能够提供访问透明性 已加入UNIX内核中 VFS保持对当前本地和远程均可用的文件集系统的跟踪，将每一个请求 发送到合适的本地系统模块上 NFS中使用的文件标识符成为文件句柄（file handle） 文件句柄对客户不透明，包含服务器区分单个文件所需要的信息 在NFS的UNIX实现中 文件集系统表示 文件集系统标识符 文件的i-node number 文件句柄： i-node generation number

11.3 SUN网络文件系统 VFS层对每一个打开的文件给一个v结点 VFS结构将远程文件系统与本地目录联系起来

11.3 SUN网络文件系统 客户集成 NFS客户------客户模块 提供适应传统应用使用的接口 精确模拟标准UNIX文件系统原语的语义并于UNIX内核集成在一起 用户可以通过UNIX系统调用访问文件，不需要重新编译或者重新加载库 客户端模块通过使用共享缓存存储最近使用的文件块，为所有用户级进程服务 传输给服务器用于认证用户ID的密钥可以由内核保存

11.3 SUN网络文件系统 访问控制和认证 与传统UNIX文件系统不同，NFS服务器是无状态的 用户每发出一个新的文件请求，服务器必须重新比对用户标识和文 件访问许可属性 Sun RPC协议发送16位用户ID和组ID，由RPC系统自动提供

11.3 SUN网络文件系统 NFS服务器接口

11.3 SUN网络文件系统 挂载服务 每个服务器中都有一个具有已知名字的文件/etc/exports 指明用于远程挂载的本地文件系统的名字和访问列表 Note: The file system mounted at /usr/students in the client is actually the sub-tree located at /export/people in Server 1; the file system mounted at /usr/staff in the client is actually the sub-tree located at /nfs/users in Server 2.

11.3 SUN网络文件系统 路径名翻译 每次使用open、create或stat系统调用时，UNIX系统将多部分文件 名转换为i-node引用 在NFS中，路径名不能在服务器上转换 一个名字可能涉及客户端的挂载结点 客户已交互方式完成路径名翻译 系统使用数个单独的对远程服务器的lookup请求

11.3 SUN网络文件系统 自动挂载器 autofs 维护一张记录挂载点和对应一个或多个NFS服务器的列表

11.3 SUN网络文件系统 服务器缓存 预先读——用于预测读访问 延迟写——用于优化写操作性能 传统UNIX系统上，磁盘上读取的文件页、目录和文件属性都保留在主缓 存区上 进程对缓存中的页面发出一个读或写的请求，系统不需要再访问磁盘就 可以完成操作 预先读——用于预测读访问 延迟写——用于优化写操作性能 当缓冲区被占用时才将该页面内容写到磁盘中 为了防止系统崩溃引起的数据丢失，每隔30s将改变写会磁盘

11.3 SUN网络文件系统 服务器缓存 NFS服务中write操作提供了两种选择项 Write操作中数据只存储在内存缓存中，当系统收到相关文件的commit 操作时，写入磁盘中

11.3 SUN网络文件系统 客户缓存 为了减少传输给服务器的请求数量，NFS客户模块将read、write、 getattr、lookup和readdir操作的结果缓存起来 客户缓存可能会导致不一致性 客户采用轮询的方式来检查他们所拥有的缓存数据是否为最新 在使用缓存块之前，使用基于时间戳的方法对缓存块进行验证 缓存中的每个数据或元数据项标记两种时间戳： Tc是缓存条目上一次被验证的时间 Tm是服务器上一次修改文件块的时间 (T- Tc <t) and (Tmclient= Tmserver)

11.3 SUN网络文件系统 客户缓存 NFS客户不知道文件是否被共享 文件属性也有Tmserver值 写操作 需要对整个文件进行验证 当一个缓存的页面被修改后，标记为脏的，通过调度异步地更新到服务 器 客户关闭文件或sync操作时，修改的页面更新到服务器

11.3 SUN网络文件系统 其他优化 Sun文件系统基于UNIX BSD快速文件系统，使用8KB磁盘块 Sun RPC的UDP数据包扩充到9KB 客户应至少3s更新在缓存的文件的状态 文件和目录的的多有操作都隐含getattr请求

11.3 SUN网络文件系统 用Kerberos实现NFS的安全性 NFS最初的标准中，用户标识已非加密的数字标识形式放置在请求中 混合方式认证 挂载主文件集系统和根文件集系统时需要使用Kerberos认证 对于每个文件访问请求，NFS服务器检查用户标识符和发送者地址

11.3 SUN网络文件系统 NFS小结 Sun NFS与抽象模型类似 访问透明性 位置透明性 移动透明性 用户看到的远程文件集路径都是在本地设置的 移动透明性 需要更新挂载表

11.3 SUN网络文件系统 NFS小结 可伸缩性 文件复制 硬件和操作系统异构性 加入服务器，重新分配文件集系统 基本所有应将和软件平台

11.3 SUN网络文件系统 NFS小结 容错 一致性 安全性 效率 NFS文件访问协议具有无状态和幂等性质 提供的语义近似于单个拷贝语义 不适用于将文件共享用于通信或在不同计算机进程间紧密合作 安全性 企业内部网 效率 效率较高

11.4 实例研究：Andrew文件系统

11.4 实例研究：Andrew文件系统 AFS为UNIX上运行的程序提供远程共享文件的透明服务 AFS与NFS的主要区别 整体文件服务 整个文件和目录的内容传输到客户机 整体文件缓存 客户机本地缓存文件

11.4 实例研究：Andrew文件系统 AFS操作场景 客户机进程向共享文件空间内的一个文件发出open系统调用，若该文件 不在本地缓存，AFS查找服务器，并向其传输此文件的一个副本 文件副本存储于客户机UNIX文件系统中，文件副本被打开，相应的描述 符传递给客户进程 客户机进程对此本地副本进行一系列的read，write操作 客户进程发出close系统调用时，如果本地文件副本发生了改变，则该文 件会被传回服务器

11.4 实例研究：Andrew文件系统 AFS性能讨论 不常更新的共享文件和只有一个用户访问的文件 本地缓存可以获得相当大的空间 基本假设 本地缓存可以在相当长的时间保持有效 本地缓存可以获得相当大的空间 可以保障经常使用的文件在缓存中 基本假设 通常文件大小比较小，大多数小于10KB 文件的读取操作比写操作更常用（通常是6倍以上） 顺序访问更常用，随机访问不常用 大多数文件只有一个用户读写，当文件被共享时，通常只有一个用户修改它 文件引用是爆发性的 如果一个文件最近被引用，在不久的将来会被再次引用

11.4.1 实现 AFS操作场景的实现问题 客户对共享文件发出open和close系统调用时，AFS怎么获得控制？ 11.4.1 实现 AFS操作场景的实现问题 客户对共享文件发出open和close系统调用时，AFS怎么获得控制？ 如果定位包含所需文件的服务器？ 客户机如何为缓存文件分配空间？ 文件被多个客户更新时，AFS怎么保证缓存中的文件副本是最新的？

Figure 12.12 File name space seen by clients of AFS Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

11.4.1 实现 客户机和服务器上的UNIX内核是修改版本 截获指向共享名字空间中文件的调用（open，close）

11.4.1 实现 客户的本地磁盘有一个文件分区用于文件缓存 11.4.1 实现 客户的本地磁盘有一个文件分区用于文件缓存 保存共享空间文件的副本 Venus进程管理这一缓存 当文件缓存已满，并且有一个新的文件需要从服务器拷贝过来时，将最 近最少使用的文件从缓存删除 共享文件空间中的每个文件和目录由类似于UFID的96位文件标识 （fid）标识，Venus进程将客户使用的文件路径名翻译为fid 用户程序使用传统的UNIX文件路径名来引用文件 Venus和Vice进程之间通信中使用fid

11.4.2 缓存的一致性 Vice为Venus进程提供文件副本时，同时提供一个回调承诺（由管理 该文件的Vice服务器发送的一种标识） 11.4.2 缓存的一致性 Vice为Venus进程提供文件副本时，同时提供一个回调承诺（由管理 该文件的Vice服务器发送的一种标识） 当其他客户修改该文件时，Vice进程会通知Venus进程 回调承诺有两个状态：有效或取消 当服务器执行更新文件请求时，通知发送过回调承诺的所有Venus 进程，Venus进程会将回调承诺标识设置为取消 当Venus进程处理客户的open请求时，先检查缓存中文件的标识 如果是取消，则必须从Vice服务器获得最新的副本 如果是有效，则可以使用和打开缓存中文件副本

11.4.2 缓存的一致性 当客户机因故障重启或关机后，Venus进程不能确定回调标识的正 确性 11.4.2 缓存的一致性 当客户机因故障重启或关机后，Venus进程不能确定回调标识的正 确性 在重启后第一次使用缓存文件或目录前，Venus要生成一个缓存有 效请求发给管理该文件的服务器，该请求包含文件修改时间戳 如果时间戳是当前的，服务器就应答一个有效信息 如果时间戳显示文件时过期的，服务器就应答一个取消信息 在打开文件之前，如果从文件被缓存开始有T时间（通常是几分钟） 没有和服务器通信了，那么回调必须更新 这样可以处理可能的通信故障

11.4.2 缓存的一致性 NFS和AFS-1中采用时间戳机制来维护一致性 基于回调的方法提供更大的可伸缩性 11.4.2 缓存的一致性 NFS和AFS-1中采用时间戳机制来维护一致性 基于回调的方法提供更大的可伸缩性 只有文件在更新时才产生客户和服务器上的通信以及其他活动 Vice进程需要维护一些Venus客户的状态信息

Figure 12.15 The main components of the Vice service interface Fetch(fid) -> attr, data Returns the attributes (status) and, optionally, the contents of file identified by the fid and records a callback promise on it. Store(fid, attr, data) Updates the attributes and (optionally) the contents of a specified file. Create() -> fid Creates a new file and records a callback promise on it. Remove(fid) Deletes the specified file. SetLock(fid, mode) Sets a lock on the specified file or directory. The mode of the lock may be shared or exclusive. Locks that are not removed expire after 30 minutes. ReleaseLock(fid) Unlocks the specified file or directory. RemoveCallback(fid) Informs server that a Venus process has flushed a file from its cache. BreakCallback(fid) This call is made by a Vice server to a Venus process. It cancels the callback promise on the relevant file. Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

11.4.2 缓存的一致性 缓存一致性机制的目标： AFS为了提供大范围的与UNIX兼容的分布式文件系统，没有提供控 制并发更新的机制 11.4.2 缓存的一致性 缓存一致性机制的目标： 在不对性能产生严重影响的情况下，近似实现单个副本文件语义 UNIX文件访问原语的单个副本语义严格要求实现，对每一个文件write操 作时，其结果必须在在对其进一步访问前发送到所有缓存中包含此文件 的计算机上 AFS为了提供大范围的与UNIX兼容的分布式文件系统，没有提供控 制并发更新的机制 一旦文件被打开，客户可以在不知道其他客户进程的情况下以任意方式 操作和更新本地副本，当文件被关闭后，上传服务器取代原来版本 不同客户进程对同一文件并发执行open，write和close后，除最后一个 close操作外，其他更新通常会丢失（没有报错）。

11.4.2 AFS 小结 针对NFS缺点 AFS 服务器端读取数量小于NFS 不能很好的进行扩展 (如果一个服务器访问特别繁忙) 对网络延迟敏感 AFS 引入客户端缓存 引入打开-关闭同步模式 引入回调机制 服务器端读取数量小于NFS

11.4.2 AFS 小结 AFS和NFS共有问题 中心服务器是瓶颈 单点故障 稳定、快速、强壮的单节点很贵

11.5 实例研究：Google文件系统

11.5.1 GFS设计概述 设计概述 系统由许多廉价的普通组件组成，组件失效是一种常态 系统存储一定数量的大文件 几千台普通的廉价设备组装的存储机器 任何给定时间内都有可能发生某些组件无法工作 应用程序bug、操作系统的bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电 源失效等造成的问题 系统存储一定数量的大文件 几百万文件 文件的大小通常在100MB或者以上 数GB大小的文件也是普遍存在

11.5.1 GFS设计概述 设计概述 系统的工作负载主要由两种读操作组成 系统的工作负载还包含大规模的、顺序的、数据追加方式的写操作 大规模的流式读取和小规模的随机读取 系统的工作负载还包含大规模的、顺序的、数据追加方式的写操作 每次写入的数据的大小和大规模读类似，数据一旦被写入后，文件就很少会被修改了 系统支持小规模的随机位置写入操作 大量并行数据处理的问题

11.5.2 GFS接口 GFS提供了一套类似传统文件系统的API接口函数 文件以分层目录的形式组织，用路径名来标识。 支持常用的操作 并不是严格按照POSIX等标准API的形式实现的 不能Mount 文件以分层目录的形式组织，用路径名来标识。 支持常用的操作 创建新文件、删除文件、打开文件、关闭文件、读和写文件 另外，GFS提供了快照和记录追加操作

11.5.3 GFS架构 GFS集群包含 GFS存储的文件都被分割成固定大小的Chunk 一个单独的Master节点 多台 Chunk服务器 并且同时被多个客户端访问 GFS存储的文件都被分割成固定大小的Chunk Master服务器会给每个Chunk分配唯一的 64位的Chunk标识 Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上 3个存储复制节点 Master节点管理所有的文件系统元数据

11.5.3 GFS架构 GFS客户端代码以库的形式被链接到客户程序里 客户端和Master节点的通信只获取元数据 所有的数据操作都是由客户端直接和Chunk服务器进行交互的。

11.5.3 GFS架构

11.5.3 GFS架构 Chunk 尺寸 Chunk的大小是关键的设计参数之一 优点 缺点 选择了64MB 通常文件block sizes 512B - 8KB 优点 减少了客户端和Master节点通讯的需求 客户端能够对一个块进行多次操作，这样就可以通过与Chunk服务器保持较 长时间的TCP连接来减少网络负载 减少Master节点需要保存的元数据的数量 缺点 小文件包含较少的Chunk，甚至只有一个Chunk。当有许多的客户 端对同一 个小文件进行多次的访问时，存储这些Chunk的Chunk服务器就会变成热点

11.5.3 GFS架构 GFS Master 单一Master节点 储存全部元数据信息 Master节点复制功能

11.5.4 GFS元数据 三种主要类型的元数据 所有的元数据都保存在 Master服务器的内存中 文件和Chunk的命名空间 操作速度非常快 周期性的状态扫描 Chunk垃圾收集 Chunk服务器失效的时重新复制数据 Chunk的迁移实现跨Chunk服务器的负载均衡 每个64MB的Chunk只有不到64个字节的元数据

11.5.4 GFS元数据 Chunk位置信息 Master服务器并不保存持久化保存哪个Chunk服务器存有指定Chunk的 副本的信息。

11.5.5 GFS系统交互 读操作

11.5.5 GFS系统交互 读操作

11.5.5 GFS系统交互 变更是一个会改变Chunk内容或者元数据的操作 变更操作会在Chunk的所有副本上执行 写入操作或者记录追加操作 变更操作会在Chunk的所有副本上执行 Master节点使用租约(lease)机制来保持多个副本间变更顺序的一致性 Master节点为Chunk的一个副本建立一个租约, 这个副本叫做主Chunk （Primary） 主 Chunk对Chunk的所有更改操作进行序列化，所有的副本都遵从这个序列 进行修改操作 修改操作全局的顺序首先由Master节点选择的租约的顺序决定，然后由租约中主 Chunk分配的序列号决定。

11.5.4 GFS元数据 写操作

11.5.4 GFS元数据 写操作

11.5.4 GFS元数据 写操作

11.5.4 GFS元数据 写操作

11.5.4 GFS元数据 写操作 客户不是发送数据到全部Chunk服务器，而是发送到某一个，之后 chunk服务器链式的传送数据

11.5.4 GFS元数据 更新操作 客户机只需要指定要写入的数据，偏移量由GFS系统给出 记录追加是一种修改操作，它也遵循上面所描述的控制流程 客户机把数据推送给文件最后一个Chunk 的所有副本，之后发送请求给主Chunk 主Chunk会检查这次记录追加操作是否会使Chunk超过最大尺寸 如果超过了最大尺寸，主 Chunk首先将当前Chunk填充到最大尺寸，之后通知所有二级 副本做同样的操作，然后回复客户机要求其对下一个Chunk重新进行记录追加操作。 如果记录不超过 Chunk的最大尺寸，主Chunk把数据追加到自己的副本内，然后通知二 级副本把数据写在跟主Chunk一样的位置上，最后回复客户机操作成功。

11.5.5 GFS总结 优化目标是大文件和顺序读取/添加 特殊的文件系统API 单Master节点设计简化协调机制，但是需要减少Master节点的任务， 并且不能利用其进行大量数据传送 在普通的硬件上实现

11.6 小结 分布式文件系统要在一致性、性能、可扩展性上进行折中 用户端缓存可以提高性能和可扩展性的工具 针对需求进行设计

Question?