操作系统中，如果libattr 功能在内核设置中被打开， ext2 、 ext3 、 ext4 、 JFS 、 ReiserFS 以及 XFS 文件系统都支持 。任何一个普通文件都可能包 扩展属性（简写为xattr, 详见 ） man xattr 含有一系列的扩展属性。每一个属性由一个名字以及与之相关联的数据所表示。其中名字必须为一个 字符串 ，并且必须有一个 命名空间 前缀标识符与一个点字符。目前存在有四种命名空间：用 ACL 存储实现就是基于这种扩展属性的。 Inode Table中保存有若干个 Ext4_inode ，每个 Inode 大小为 ext4_super_block 中指定的 s_inode_size, 然而一个 Inode 不一定用到这么多的大小，节点信息只用到 128 个字节的空间。剩下的部分作为扩展文件属性 (Xattr)，扩展属性内部是由一个扩展属性头和若干个扩展属性实体项构成的。© XXX getfacl接口文件系统自己如何实现 chmod、chown 可以通过setattr接口实现 setfacl、getfacl通过setxattr、getxattr接口实现，需要在Inode中增加扩展属性 root@pubbeta2-curve5:/tmp# strace getfacl acl.test execve("/usr/bin/getfacl", ["getfacl", "acl.test"]

inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 小文件优化 空间管理单位 数据持久化 其他© XXX Page 3 of 24 moosefs（mfs） 有元数据服务器 全内存 fsnode → hashtable(inode id) fsedge binlog，随时间会越来越大 差 DG Master/Slave glusterfs 无中心化服务器 dht算法 hash 扩展时大量迁移 client缓存 inode→ hashtable(gfid) dentry→ hashtable(name) inode扩展属性字段 和写数据一样 好 写多份 overwirte有数据不一致风险 curve 有元数据服务器 lru cache缓存 需要消耗比较多的内存，元数据服务的扩展性受限于内存，而且在元数据服务启动的 时候，需要等待一段时间加载内存。 一种是元数据需要全部加载到内存，这种情况下，元数据只需要加载一小部分主要的元数据，比如说super block这种，剩下的比如inode，dentry这种，按需加载，而且使用淘汰机制，内存中不常用的元数据可以淘汰出去。这种方式，扩展性好，元数据服务的扩展性不受限于内存，服务上的内存只有几百GB，而硬盘空

list：list在通用文件系统中是很常见的操作，目前 curve 的元数据缓存使用的 lru cache，因此 list 只能依赖 etcd 的 range 获取方式。如果需要对 list 加速，需要新的缓存结构 c. 扩展性/可用性/可靠性 依赖于第三方kv存储，目前是etcd CurveFS 单机内存元数据设计 类似 fastcfs 和 moosefs 的元数据设计方式，采用通用的 dentry，inode a. 性能 加载：数据量较大的情况下，元数据节点启动较慢；但是元数据使用 master-slave 可以降低 failover 情况下的加载时间 b. 扩展性/可用性/可靠性 扩展性不够，受限于单机的内存和磁盘，只能纵向扩展 可用性足够，由于是 master-slave 的方式，master 以同步方式调用 slave，slave 在内存中也缓存了全部元数据信息 master-slave 持久化元数据以及保证多副本数据一致性。基于这种方式开发： a. 性能 由于元数据分片，获取元数据需要跟多个节点进行rpc的交互，因此性能相比单机要弱一些 b. 扩展性/可用性/可靠性 使用 multi-raft, 扩展性、可用性和可靠性与元数据节点一致 对比结论 CurveFS 近期要能支持mysql所要接口，长期需要支持通用文件接口。 kv 虽然改造简单，短期内对基本功能的支持没有问题，但这个架构不利于

易用性：跨平台，超融合，弹性 小型主机 容量有限分布式存储的分类 按照各种应用场景所需的存储接口分类 对象 存储 文件 存储 块存储 接口为简单的 Get、PUT、DEL 和其他扩展 通常意义是支持 POSIX 接口 传统意义的文件系统： Ext4 对指定地址空间进行随机读写 传统意义的块存储：磁盘分布式存储的要素 如何构建分布式文件系统？ 以分布式块存储为例。 •提供大容量的块设备 可靠性 & 可用性 —— 多副本/EC 服务不可用时 间 数据一致性 —— 一致性协议 如何保证数据不丢？如何保证各种硬件故障的时候读 写都正常？ 可扩展性 —— 和数据分布的方式相关 所用容量都用完后，可以新增机器扩展容量分布式存储的要素 — 数据分布 无中心节点：哈希算法 INPUT (Offset, Len) HASH HASH mod 72 (DiskNums) (0

CLup管理节点2 高可用机制自动切换  数据一致性保证 数据可用性  提供读写VIP  读写高可用 读写分离  多个读库之间负载均衡 负载均衡  读线性扩展  支持分库分表 高扩展性 写 VIP 读 VIP PG (Primary) PG (Standby1) PG (Standby2) PG (Standby3) 数据同步复制 写请求 读请求

业务驱动下的分布式技术实践之路 5月17日，支付宝最后一台小型 机下线标志去IOE落下帷幕 首次双十一大考卡顿半分钟后稳 定度过 7月，TDDL+AliSQL首次验证支 持核心库 无法弹性扩展 成本高 去 IOE 商品库去O TDDL首次双十一 “去IOE完成” 天价账单 上云 2009 2011 2012 2013 2013 2015 TDDL 以中间件形态在阿里云上 发布:

NebdServer实现大部分的客 户端逻辑Curve块存储 故障对I/O抖动延迟的影响 FAULTS CASE CURVE I/O 抖动Curve文件存储 1. 元数据服务 2. 高性能 3. 可扩展易运维 4. 云原生 设计目标Curve文件存储 1. 兼顾性能与容量的机器学习 场景 2. 快速跨云弹性发布的业务 3. 低成本大容量需求的业务 4. 中间件冷热数据自动分离 5.

• 纯用户态，不与内核绑定 • 支持复杂的存储系统，例如ceph rbd, sheepdog, glfs • 纯C代码，外加一些脚本 • 完整的源代码和维护工具、手册 • 编写IO驱动比较容易，容易扩展支持新的存储系统 • 代码独立，容易编译、调试、修改，适应性强让TGT支持curve • 编写curve驱动，底层异步提交I/O，pipeline • 利用NEBD PART 1接口，需要与nebdserver运行在同一台机器

mapCurve社区介绍 • Curve 的成⻓离不开⼤家的⽀持和参与。⾮常欢迎社区⽤户参与社区共建，可以 通过贡献代码、丰富⽂档、提交issue、改进⽹站、交流分享等，提⾼⾃⼰专业 能⼒的同时还可以提升个⼈影响⼒、扩展⼈脉。 • 项⽬https://github.com/opencurve/curve • 版本发布周期：每半年⼀个⼤版本，1～2个⽉⼀个⼩版本 • 了解Curve进展：每隔2周的Curv

快照克隆服务器 独立于核心服务 储到支持S3接口的 对象存储，不限制数量 异步快照、增量快照 从快照/镜像克隆 ( lazy/非lazy ) 从快照回滚数据组织形式 • 底层 可用性 / 可靠性 扩展性 / 负载均衡 向上提供无差别文件流 • Application 块/对象/EC等 感知具体格式 提供不同文件类型支撑不同上层应用数据组织形式 • PageFile/AppendFile/AppendECFile