· 3.1 文件 I/O 和性能
· 当一个进程打开一个文件,客户端发送一个请求给 MDS 集群,
MDS 转换文件名为文件 inode,这个 inode 包含唯一的 inode 号、文
件所有者信息,模式,大小和其他的 per-=le 元数据,如果文件存在并
且访问被允许,MDS 会返回 inode 号、文件大小以及文件数据到对象
的条带化映射策略的相关信息,MDS 可能给客户端一个权限(如果之前
没分配),这个权限指明何种操作被许可,现在权限包含四种:分别控
制客户端的读,缓存读,写,缓存写,将来可能包含加密钥(让客户向
OSD 证明他们被授权去读写数据『现在的原型相信所有的 client)。此
外,MDS 还会管理文件的一致性语义。
· Ceph 用一系列条带化策略管理文件数据到对象序列的映射,为了
避免任何文件分布的元数据, 对象名称简单地由文件 inode 编号和条带
编号结成,然后对象副本利用 CRUSH 算法分布到 OSD 集群,举例来说,
当一个或多个客户端打开一个文件以进行读访问, MDS 负责授权客户端
读和缓存文件内容。当拥有 inode 号、文件格式和文件大小, 客户端能
够得到包含文件数据的所有对象的名称和位置,并且是直接从 OSD 集群
读取的。任何对象或字节范围如果不存在就被定义为“文件洞”, 或空。类
似地, 如果一个客户端打开一个文件进行写操作,则被授权 bu>er 写,它
在文件中任何字节生成的任何数据都会被写入适当的 OSD 中的对象上,
客户端不再关闭文件,而是提供给 MDS 新的文件大小(最大的写入字节
数)。
· 3.2 客户端同步
· POSIX 语义要求读先于写,写是原子写(如: 内容的覆盖,并发写会
有顺序问题),当一个文件被打开,被多个客户端写或者读+写,MDS
将撤销之前的问题读缓存和写缓冲,强制客户端进行文件同步 I/O,每
个应用读与写操作都会阻塞直到被 OSD 授权,OSD 存储对象能够有效
的分担更新序列化和同步的负载。当一个写跨越一个对象边界,客户端
获得所有受影响对象的独占锁(相关 OSD 赋予他们的), 立刻提交写和解
锁操作去达到序列化要求,对象锁也用于掩盖需要锁和大型异步写的延
迟。
· 毫不奇怪,同步 I/O 对于应用来说是一个性能的杀手,尤其进行小
文件的读写操作时,因为存在至少一个到 osd 的来回的延迟消耗,尽管
读写共享在平常操作中比较少,更多时候用于科学计算,在这些地方性
能表现很好,因为这个原因,当应用对一致性要求不高时往往可放松一
致性语义,Ceph 也实现了放松一致性语义,可以通过全局配置项配置,
其他文件系统也做了这个设计, 但这个设计确实不是一个很好的方案。
· 因为这个原因, POSIX 上一些高性能计算的扩展被 HPC 社区应用