cxljs

JuiceFS 设计和实现

分布式文件系统的发展

Google GFS 的发表是分布式文件系统发展的里程碑，Meta + Data 的架构影响了后来的分布式系统设计。随后的 HDFS 是大数据时代最重要的存储系统之一，现在分布式文件系统最流行的2种接口协议是 POSIX 和 HDFS。

随着云原生和对象存储的发展，数据系统的设计趋势是把数据放到对象存储，比如 autoMQ 把 Kafka 的数据放到对象存储，AWS 刚发布的基于对象存储的向量数据库。

现在 LLM 时代对分布式文件系统的需求也有变化，相比大数据时代，AI 训练存储的更多是小文件，所以文件系统的元数据更多。LLM 时代的分布式文件系统还有一个热点是 GPU Direct FS。

分布式文件系统的挑战

文件系统的元数据组成一个 DAG，分布式文件系统的挑战之一在于：

  1. 怎么存储这个 DAG?
  2. 怎么高并发读写这个 DAG?

常见思路：

  1. 整个 DAG 存储在单个节点（主备模式），缺点是单节点吞吐量和容量有限，可能会成为系统瓶颈
  2. 设计一个可扩展的存储 DAG 的系统，把 DAG 划分存储到多个节点，目前有相关的论文，但是没有这样做的开源项目(CubeFS 好像是?)
  3. 转化成 KV/Table 数据模型存储在 KV/RDB
  4. 不采用 Meta + Data 架构，把 Meta 和 Data 混合存储（10年前有这样做的系统，现在应该没有）

JuiceFS

JuiceFS 是经典的 client-meta-data 架构，采用第3种思路存储元数据，支持 TiKV/MySQL/Etcd/Redis 等多个系统作为 Meta Service，数据放在对象存储，JuiceFS 本身是一个 client 层。

架构：

app          fuse  -->  juicefs --> meta service
 |            |            |
 |            |             --> object storage service
syscall    /dev/fuse
 |            |
vfs    -->   fuse

文件存储模型

如果一个文件作为一个对象去存储，修改文件会有严重的写放大，特别是大文件，所以需要把文件划分成多个对象去存储。

为此 JuiceFS 设计了 chunk-slice-block 模型：

  • 文件逻辑上划分成多个 chunk，chunk size = 64MB
  • 对 chunk 的每次写为一个 slice，slice = (chunk id, offset, size, data)，data 存储在 local data cache，多次写可能有重叠，所以还要记录 slice 顺序，以最新的为准。跨 chunk 的写会分成多个 slice
  • 把 local data cache 的 slice 存储到对象存储时，把一个 slice 作为一个对象去存储？为了提高 slice 写到对象存储的速度，把 slice 划分成多个 block (block size = 4M) 并发写入

所以对象存储的对象是一个个 <= 4M 的 block。

对象名：${fsname}/chunks/${hash}/${basename}:

  • fsname: 用户定义的文件系统名字
  • hash: hash_func(basename)，为了做隔离
  • basename: 对象的有效名字，格式是 ${slice_id}_${block_index}_${block_size}，block_index 是 block 在 slice 的序号，范围 [0,15]

多个写重叠会产生垃圾 slice -> 产生垃圾 block，所以需要删除，还可以做合并碎片等设计。

上面说每次写是一个 slice，实际上由于有 local data cache，JuiceFS 做了一些优化，比如一次写后，slice 还没有上传到对象存储，此时有新的写操作和它重叠或连续，会直接修改它，不创建新 slice。

元数据存储模型

JuiceFS 需要维护的元数据：

  • 系统元数据
  • 各种计数值：下个可用的 inode id, slice id, session id, &c
  • session: client id, info 和超时时间
  • inode attr：type, size, nlink, uid, parent inode id, &c
  • file inode data (chunks): (inode id, chunk index) -> []sliceMeta
  • dir inode data：(parent inode id, name) -> (type, inode id)，即(目录 inode id, 子 inode 名字) -> (子 inode type, id)
  • plock: (inode, session id, owner) -> []plock record
  • …

JuiceFS 需要设计合理的数据模型，把元数据放到 TiKV/MySQL/Redis 等系统。

Redis：

  • 系统元数据：string KV ：setting -> json string
  • 各种计数值：string KV ：nextInode -> num, nextSliceId -> num, &c
  • session
    • session timeout: allSessions -> a sorted set {member: client id, score: timeout timestamp}
    • session info: sessionInfos -> a hash table {client id -> json string}
  • inode attr: string KV: i${inode_id} -> 二进制编码的 attr struct
  • chunk: c${inode_id}_{chunk_index} -> list {二进制编码的 sliceMeta struct}
  • dir: d${inode_id} -> a hash table {name -> 二进制编码的 (type, inode_id)}
  • …

用只有 KV API 的系统作为 Meta Service 时，string KV 不变，hash table 等需要把 key 和 field 拼接成一个 key：

  • 系统元数据：setting -> json string
  • session
    • SE${client_id} -> timeout timestamp
    • SI${client_id} -> json string
  • inode attr: A${inode_id}I -> 二进制编码的 attr struct
  • chunk: A${inode_id}C${chunk_index} -> 二进制编码的 sliceMeta array
  • dir: A${inode_id}D${name} -> 二进制编码的 (type, inode_id)
  • …

key 的具体拼接细节没有保持一致，但无伤大雅。

用数据库作为 Meta Service，元数据分成多个表存放，本质上差不多。

以读文件数据为例，流程是：

  1. root inode id = 1, 根据文件路径，找到 inode_id, size(in attr)
  2. 计算要读的 chunk_index, c${inode_id}_{chunk_index} 获取 slice meta list
  3. 计算要读的位置在哪些 slices 以及在 slice 内的 index，${slice_id}_${block_index}_${block_size} 读取 block，拼接数据

架构

JuiceFS 内部主要有3个模块：vfs, meta store 和 chunk store:

  • vfs: 以文件系统的视角，维护需要的元数据，做相关的检查，调用 meta store 和 chunk store
  • meta store: cache + meta service cli，获取元数据时，会先查看 cache，减少对远程 meta service 的压力
  • chunk store: data cache + oss cli + 预读策略

具体看代码，chunk store 的接口设计很漂亮。