用户权限系统调研（已实现）© 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）中增加

因此需要通过Cache模块解决以上2个问题。 整体设计 整个dataCache的设计思路，在写场景下能将数据尽可能的合并后flush到s3上，在读场景上，能够预读1个block大小，减少顺序读对于底层s3的访问频次。从这个思路上该缓存方案主要针对的场景是顺序写和顺序 读，而对于随机写和随机读来说也会有一定性能提升，但效果可能不会太好。 元数据采用2层索引 由于chunk大小是固定的（默认64M），所以Inode中采用map控制处于wait状态。 2.write流程会对后台线程处于wait状态的情况触发notify唤醒，同时修改DataCacheNum_。 3.后台会遍历DataCache，达到flushwait的时间，或者DataCache

⾼性能、易运维、云原⽣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以内 • 瓶颈

目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup count未考虑： lookup count 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会造成崩溃或报错，我们的curvefs也需要实现 即使文件/目录已经被另一个进程删除了（nlink==0） 这样的语义。 这部分内容在fuse的相关接口中也有描述如下： ，则不会立即将该文件彻底删除，而是将其类型修改为TYPE_TRASH并且将该节点从文件树移除然后放到trash链表中表示该文件已经进入回收 若其trashtime大于0 站。 通过META文件系统来访问trash 通过trash机制，可实现文件的恢复UNDEL 回收站实现了一个timer，定期判断trashtime，执行定期清理回收站 清理时，当文件仍处于打开状态，则还需要进入下sustained/reserve中。 deid,所以不影响它对该文件的读写操作，当所有客户端都关闭该文件后，该文 件节点才会从 被清除。 reserve 使用了session机制，记录client端的open状态 通过META文件系统访问reserve 使用CUTOMA_FUSE_RESERVED_INODES消息保持和释放inode 实现了Timer，定期判断是否还有session，如果没有client打开，则进行清理。 优点：

C u r v e 质 量 、 监 控 与 运 维 秦 亦 1/33背景 01 02 03 04 Curve质量控制 Curve监控体系 Curve运维体系Curve 是网易针对块存储、对象存储、云原生数据库、EC等 多种场景自研的分布式存储系统：  高性能、低延迟  当前实现了高性能块存储，对接OpenStack和 K8s  网易内部线上无故障稳定运行近两年  已完整开源 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 03 04 Curve质量控制 Curve监控体系 Curve运维体系软件质量 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  完美兼容Jenkins ci  丰富的第三方库（ssh, paramiko, request等） 用例设计原则  无需绑定特定环境，“随意拉起”  配置化（测试环境、测试负载定义）  控制用例时间（考虑一些折中方案）  Case独立性  Case通用性（兼顾curve、ceph等）  Tag规范(优先级、版本、运行时间)  最大化覆盖率（打乱操作顺序、随机 sleep）

ChunkServer架构Metric统计模块使用brpc中的bvar计数 器，统计一些IO层面和copyset层面的 一些指标，方便监控和跟踪。 ChunkServer架构并发控制层，负责对chunkserver的IO 请求进行并发控制，对上层的读写请 求安照chunk粒度进行Hash，使得不同 chunk的请求可以并发执行。 ChunkServer架构DataStore是对chunk落盘逻辑的封装。

云原生 设计目标Curve文件存储 1. 兼顾性能与容量的机器学习 场景 2. 快速跨云弹性发布的业务 3. 低成本大容量需求的业务 4. 中间件冷热数据自动分离 5. S3和POSIX统一访问需求 主要挑战和支持场景Curve Roadmap 1. 架构 1. 文件存储支持分布式缓存、完善冷热数据分层存储能力 2. 完善混合云、公有云上部署架构 3. 完善高性能3副本存储引擎，支持混合盘

MDS、Snapshotcloneserver 通过 etcd 选主，实现高可用高可用 chunkserver 使用raft，2N + 1 个副本允许 N 副本异常自治 • 自动故障恢复 • 多对多，恢复时间短 • 精确的流量控制，对io几乎无影响自治 • 集群负载和资源均衡 • leader copyset scatter-width • 无需人工干预 • 对io影响几乎无影响易运维 • 升级秒级影响 • 客户端采用CS架构

com/opencurve/curve-csi CLIENT上层应用CLIENT虚拟块设备CLIENT主要功能  提供接口  数据面：AioWrite/AioRead、Write/Read  控制面：Create/Delete、Open/Close、Rename等  IO处理：转换、拆分、合并  元数据获取及缓存  逻辑chunk与物理chunk映射关系  物理chunk所属的复制组(copyset)

Ucp Context ●只有一个全局对象，使用下列函数获取 ●UCP_Context* get_or_create_ucp_ctx() ●指定了FEATURE_AM, 多线程共享39 命令行参数控制context的属性 ●--brpc_ucp_error_mode缺省是none，是的本地通讯使用shared memory成为可能 ●--brpc_set_cpu_latency 非-1, 设置intel