文档介绍了分布式文件系统的定义及其分类，涵盖了如 Google 文件系统、FastDFS 等具体实施。它讨论了技术挑战，如高容量、大并发和系统稳定性，并对多种文件系统架构进行了比较。最后，阐述了设计分布式文件系统时需考虑的权衡因素。

1. Distributed Filesystem Ning Peng

2. 定义 A file system (often also written as filesystem ) is a method of storing and organizing computer files and their data. Essentially, it organizes these files into a database for the storage, organization, manipulation, and retrieval by the computer's operating system.

3. Challenge NTFS / EXT3 等工作得很好 NFS 在很多场合也还不错 但是…

4. Challenge 更高的容量 大容量媒体文件 - PB 海量的文件 – Trillion

5. Challenge 更强的性能

6. Challenge 更低的价格

7. Challange 稳定可靠 磁盘损坏 部件失效：主机，接口，控制器，电源，网络 ...

8. How to scale 本来应该说是 Scale Your Storage 这个 topic 太大 涉及到应用，硬件，网络 先简单的谈分布式文件系统 谈点穷人的方案

9. 看看我们有的文件系统 太多了…看分类吧 Disk file systems –ext3/ntfs/zfs/wafl ( 大部分我们熟悉的 ) File systems with built in fault-tolerance-zfs/brfs File systems optimized for flash memory, solid state media Record-oriented file systems Shared disk file systems Distributed file systems Distributed fault-tolerant file systems Distributed parallel file systems Distributed parallel fault-tolerant file systems GoogleFilesystem/CloudStore/Lustre/HDFS Peer-to-peer file systems Special purpose file systems Pseudo- and virtual file systems Encrypted file systems

10. Google File system Like Google File system KFS HDFS Why like? Master – chunk 架构 POSIX Like Interface 设计目标一致

11. GFS Goal 最开始是为爬虫等应用设计的 The system is built from many inexpensive commodity components that often fail. The system stores a modest number of large Files. large streaming reads and small random reads The workloads also have many large, sequential writes that append data to Files High sustained bandwidth is more important than low latency

12. GFS Architecture

13. GFS Architecture 文件分块 大小 64MB 为什么是这个大小？ Master 管理元数据 Namespace File Attributes Chunks , and location Single Master ? Yes Simple

14. Master 设计 都放在内存里 64MB Chunk -> 64 bytes Log & Check Point

15. 一致性 Master 控制的部分是一致的 创建删除文件等 串行写 - 一致已定义 并行写 – 一致未定义

16. Write Process

17. GFS 限制 显而易见的单点故障点和性能瓶颈 从几百 TB 到几十 PB 更多的 metadata 更大的容量 更多的 housekeeping 工作耗时 客户端并发的限制 解决 Multi-cell / Pratition Namespace 层面解决问题

18. MogileFS Application level No single point of failure Automatic file replication "Better than RAID" Flat Namespace Shared-Nothing / No RAID required Local filesystem agnostic

19. MogileFS Overview Application Tracker DB Metadata & location Need HA Storage Nodes NFS or HTTP transport

20. Read Request

21. MogileFS 特点 和 Google FS like 的相似 Metadata 信息 不同 Chunk replication vs file Replication 限制 DB 是主要的瓶颈

22. FastDFS FastDFS 是一个轻量级的开源分布式文件系统 FastDFS 主要解决了大容量的文件存储和高并发访问的问题，文件存取时实现了负载均衡 FastDFS 实现了软件方式的 RAID ，可以使用廉价的 IDE 硬盘进行存储 支持存储服务器在线扩容 支持相同内容的文件只保存一份，节约磁盘空间 FastDFS 只能通过 Client API 访问，不支持 POSIX 访问方式 FastDFS 特别适合大中型网站使用，用来存储资源文件（如：图片、文档、音频、视频等等）

23. FastDFS

24. FastDFS 构成 Tracker Server 主要做调度工作，在访问上起负载均衡的作用。记录 storage server 的状态，是连接 Client 和 Storage server 的枢纽。 Storage Server 存储服务器，文件物理内容和 meta data 都保存到存储服务器上 Storage Server 构成不同的组 ( 卷 /Volume) 同组的 Storage Server 的文件是相同的

25. FastDFS 基本流程 -PUT client 询问 tracker 上传到的 storage ，不需要附加参数； tracker 返回一台可用的 storage ； client 直接和 storage 通讯完成文件上传。

26. FastDFS 基本流程 -GET client 询问 tracker 下载文件的 storage ，参数为文件标识（卷名和文件名） tracker 返回一台可用的 storage ； client 直接和 storage 通讯完成文件下载。

27. FastDFS 特点 异常的简单高效 对等结构 分组存取 Tracker 的责任很简单 只做调度，所以性能不是问题 文件不分 CHUNK 适合于大量小文件存取 同一组内的服务器的文件完全相同的 组之间没有运行中的动态负载均衡 文件名是 FastDFS 指定而非 Client 指定 对 ClientApplication 要求较高，限制了使用场景

28. DFS 设计考虑因素 Tradeoff … Tradeoff 高吞吐 、 IOPS 海量 、 大文件 可靠性，可用性 易于开发，易于管理，成本 我的 File 的类型大小，访问模式 我对共享访问的需求 特别是一致性 我对并行访问的需求

29. 我的性能瓶颈在哪里 存储介质 读写流程 存储路径 Cache

30. DFS 的一些因素的分析 1 st – 我真的需要吗？ POSIX Interface Access mode support RAID / Chunk Replication / File Replication NameSpace Management Metadata Management Out-band mode Cache Access Interface MetaServer topo Single / Active Standby / Peer / Hash or ……

31. Reference & Thanks wikipedia gfs-sosp2003.pdf http://www.danga.com/mogilefs/ FastDFS – 余庆

32. Q & A msn: pengning_cn #AT# hotmail.com 谢谢大家！