The Google File System [SOSP‘03] 论文阅读笔记

原论文：The Google File System

1. Introduction

• 组件故障是常态而非例外
  • 因此，我们需要持续监控、错误检测、容错和自动恢复！
• 按照传统标准，文件数量巨大
• 大多数文件都是通过添加新数据而不是覆盖现有数据来改变的，因此文件内的随机写入几乎不存在
  • 因此，追加成为性能优化和原子性保证的重点！

2. Design Overview

2.1 Architecture

• 组成：单个master、多个chunkservers、多个clients
• master维护所有文件系统元数据
• 文件被分成固定大小的块
• clients和chunkservers都不缓存文件数据

2.2 Single Master

• 设计目标：尽量减少其参与读写的次数，以免master成为性能瓶颈
• clients会在一定时间内缓存最新访问的chunkservers的信息

2.3 Large chunk size as 64 MB

• 优点
  • 减少clients与master交互的需要，对同一数据块的读取和写入只需向master发出一次初始请求，以获取数据块位置信息
  • 在一个大块上，clients更有可能对一个给定的块执行许多操作，它可以通过长时间保持与chunkservers的持久 TCP 连接来减少网络开销
  • 减少存储在主服务器上的元数据的大小
• 缺点
  • 数百台机器同时访问的单块热文件时导致某个chunkserver超负荷运行
    • 解决方案：允许clients从其他clients读取数据

2.4 Metadata

• 元数据主要包括：文件与chunk的命名空间（记录日志）、文件与 chunk 之间的映射关系（记录日志）、每个 chunk replica 所在的位置
• 元数据存储在内存中，每个chunk有大概64字节的元数据
• 控制所有块的放置，通过定期的 HeartBeat 消息监控chunkservers的状态来记录chunk的位置
• 操作日志
  • 只有在本地和远程将相应的日志记录刷新到磁盘后&#