", inode = " << dentry.inodeid(); return ret; } return ret; } 存在两个问题: 一是删除时nlink字段未考虑： 文件的nlink用于实现hard link。 hard link使用nlink字段表示文件的link的引用计数，第一次创建文件是nlink字段为1。每创建一个新的指向该文件的hard link时 目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup count未考虑： lookup count 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会造成崩溃或报错，我们的curvefs也需要实现 即使文件/目录已经被另一个进程删除了（nlink==0） 这样的语义。 这部分内容在fuse的相关接口中也有描述如下： 当umount时，所有lookup count减至0 不应该完全依赖forget接口去实现inode的移除，因为forget接口可能不会被内核调用（例如client崩溃） 相关调研 moosefs moosefs 未对接forget moosefs 实现了在mds上open，因此删除时可以判断文件是否被打开 moosefs使用了两种机制，来实现上述功能，分别是trash机制和reserve机制（最新版本叫sustained），两种机制如下：

用户权限系统调研（已实现）© XXX Page 2 of 33 一、Curvefs测试 1. 启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 文件权限 特殊权限(SUID, SGID, STICKY) 文件默认权限umask -o conf=./curvefs/conf/curvefs_client.conf /tmp/fsmount 问题1：root用户无法访问挂载目录 测试发现client mount进程是哪个用户启动的就只有该用户(filesystem owner)可以访问该目录，即使挂载点mode是777。 # filesystem owner wanghai01@pubbeta1-nostest2:/tmp$ XXX Page 4 of 33 查阅资料发现这是fuse的一种安全策略，默认是只有filesystem owner拥有该文件系统的访问权限，如果想要其他用户有权访问，需要在挂载参数中指定‘-o allow-root’ 或'-o allow-other'以允许相应用户有权访问该文件系统，如果挂载者不是root还需要在/etc/fuse.conf（/usr/local/etc/fuse.conf）中增加

chunk的cur_sn时触发复制  拷贝的单位是一个Page，即4KB  使用snapfile中的bitmap标记复制过的PageCHUNKSERVER端快照实现-转储内部快照 a) 打快照后未写过，未触发cow， 无snap file产生，直接读取chunk file b) 打快照后写过，触发了cow， 有snap file， 合并读取 c) 卷从未写过， 两者都没有，返回NOTEXIST 使用chunkfile的bitmap来标记写过的Page， 一个Page大小为4KB • 读请求到来时，根据bitmap中的信息， • 对于已写过的区域，从本地chunk file读 • 对于未写过的区域，从远端源chunk file读 • 之后，将两者合并返回。 • 同时把源chunk读到的数据异步写入到本地 chunk，并标记bitmap，这个过程称之为 PasteChunk

（这里涉及到一个问题，是否从fuse下来的请求是4k对齐的，如果不是，那么这里还需要修改为read merge write，即读出未对齐缺少的部分，然后整个[offset,len] 调用curve client写）; 修改inode结构，如果上述区域存在先前未写过的区域，则需要去掉unwritten，具体方式根据inode结构而定；inode修改需要持久化到底层并修改本地cache；© XXX ds获取inode所在copyset，metaserver ip等信息，然后从metaserver获取inode结构，缓存之； 根据inode结构，拆分unwritten/未分配的区域与写过的区域，未写过的区域填0，其他区域继续读取 根据inode结构中信息，调用curve client接口，读取对应的[offset, len]数据。（这里同样要考虑4k对齐的问题，如果不对齐，则需要读取对齐的区域

⾼性能、易运维、云原⽣Curve⽂件系统框架和主要应⽤场景 • AI机器学习场景 • ⼤数据计算场景 • 中间件数据存储场景 • ⽀持POSIX兼容的⽂件API • ⽀持低延迟的⽂件数据访问Curve⽂件系统⾯临的问题 • ⽤户态实现 • 稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4 根据UID，ATIME，CTIME，length来设置属性 • 关闭⽂件时会发送FLUSH请求和RELEASE请求FUSE⽂件IO读写流程FUSE的IO路径及瓶颈分析 • 对⽐测试 • ⽂件访问测试直接访问ext4 • 通过FUSE访问passthrough_ll底层ext4 • 内核调⽤延迟测试 • 与FUSE Daemon通讯120us左右，FUSE Daemon⼤概10us以内 • 瓶颈

后再把本地缓存 硬盘中的数据异步上传到远端对象存储。 方案设计© XXX Page 3 of 9 S3模块接收到写入后先写入写内存缓存页，如果满足持久化的条件后，那么则准备持久化。 如果未配置本地硬盘作为写缓存，那么直接持久化到远端的对象存储；如果配置了本地硬盘作为写缓存，那么则尝试先写入本地硬盘写缓存目录。 写本地硬盘缓存目录之前先判断缓存目录容量是否已达到阈值，如果已经达到阈值，

不支持热升级，需要业务停服 集群监控 丰富的metric metric类型较少主要亮点 — 更稳定 异常场景 Curve Ceph 坏盘 基本无抖动 无明显抖动 慢盘 io持续抖动，但util未100% io持续抖动，util持续100% 网络丢包 随着loss增大，还有部分io 随着loss增大，无法进行io 机器宕机 io略微波动 io卡住10s以上 机器卡住 io抖动4s 不可恢复主要亮点

ll的时长 –--brpc_ucp_deliver_out_of_order为true，接收端乱序提交 –--brpc_ucp_close_flush，release connection时发送未未完成的报文，不是必须的，因为 brpc通常是需要接收应答的,服务器端一般不主动关闭连接，客户端主动关闭，自己负 责是否有未接收完的应答。56 修改BRPC的EndPoint ●原始的EndPoi

Chunkserver使用基于ext4实现的本地文件系统，由于写操作存在较大的IO放大，因此在创建chunk 文件时会调用fallocate为文件预分配固定大小的空间，但是即便fallocate以后，在写文件未写过的块 时仍需要更改元数据，存在一定的IO放大。 解决思路： 直接使用覆盖写过一遍的文件。由于chunk大小固定，预先生成一批被写过的固定大小文件。创建 chunk文件或快照文件时直接从预分配的

chunkserver状态改为offline， 打印一条error日志。调度模块感知到offline状态， 触发chunk server的recover修复。 心跳正常 心跳正常 超过miss时间 未超过offline时间 UNSTABLE ONLINE OFFLINESCHEDULE Schedule（系统调度）是为了实现系统的自动容错和负载均衡，这两个功能是分布式 存储系统的核心问题，也是