目录的nlink字段与文件的nlink字段不同， ， 并且在目录下， ， 删除目录nlink相应的减1。 目录的nlink字段初始值为2 每创建一个新目录，nlink字段也会+1 目录不支持硬链接。 二是删除时lookup count未考虑： lookup count 指的是文件的访问计数。当文件/目录被打开时， ，该文件/目录仍然可以被打开的进程访问，不会造成崩溃或报错，我们的curvefs也需要实现 能需要引入额外的复杂性，但是依然可以实现简单的 工具查询。 由于该方案，删除的inode是分散于每个partition中，那么查询工具可能需要遍历所有partion去查询所有的删除inode。 第二种方案： 将inode移动到隐藏的trash目录，这个trash目录可以是实际的目录结构，有dentry和inode，并遵循当前inode和dentry的放置方式（inode按照inodeid分布，dentry按照parentid分布） 但是缺点是DEL和UNDEL需 ，这部分处理会引入 。（这个过程其实类似于rename） 要在trash下创建和删除dentry 额外的复杂性 由于moose是单文件系统，对于我们实现多文件系统，这里还有两种方案： ，二是每个fs一个trash，并且trash不能放在fs的根目录下，因为存在跟用户的目录重名的问题。 一是使用全局唯一的trash 倾向于使用方案1，各方面实现上较为简单，异常处理不会很复杂，查询工具可以先实现一个简单的。

李小翠、吴汉卿、许超杰等 补充文件空间分配，讨论与确认 背景 调研 开源fs 性能对比 可行性分析 方案对比 对比结论 架构设计 卷和文件系统 元数据架构 文件系统快照 方案一：文件/目录级别快照 方案二：文件系统快照 关键点 元数据设计 数据结构 索引设计 文件空间管理 开发计划及安排 背景 为更好的支持云原生的场景，Curve需要支持高性能通用文件系统，其中高性能主要是适配云原生数据库 XXX Page 8 of 14 快照的cow© XXX Page 9 of 14 优势在于可以做lazy-copy，速度很快。 劣势在于当前的快照逻辑复用需要做较大变动 方案二：文件系统快照 复用当前的逻辑，文件系统快照就是当前卷的快照，因此数据的快照就已经有了，需要的就是元数据的快照。© XXX Page 10 of 14 1. 1. 2. 3. 2 这种方式相当于每次都是全量缓存当前元数据，不做增量快照，考虑到转储逻辑，这也是可以接受的 对比这两种方案，第一种方案对于copy场景是友好的，但需要重新实现一套快照逻辑；第二种方案的改动和实现相对简单，并且对于需要备份的场景也是够用的。从可解决程度和解决的必要性考虑，选择第二种方 案。 关键点 mds volume 文件空间管理 文件系统的元数据所在的copyset分配策略（前期可以考虑都分配到同一个copyset上）

MDS1、MDS2、MDS3的租约全部过期 4.2.4.4 总结 4.2.5 异常情况四: Etcd集群与MDS1(当前leader)出现网络分区 4.2.5.1 事件一先发生 4.2.5.2 事件二先发生 4.2.6 异常情况4：Etcd集群的follower节点异常 4.2.7 各情况汇总 1. 需求 mds是元数据节点，负责空间分配，集群状态监控，集群节点间的资源均衡等，mds故障可能会导致client端无法写入。 需要解决的问题就是：如何确定主备节点。 2. 技术选型 提供配置共享和服务发现的系统比较多，其中最为大家熟知的就是zookeeper和etcd, 考虑当前系统中mds有两个外部依赖模块，一是mysql， 用于存储集群拓扑的相关信息；二是etcd，用于存储文件的元数据信息。而etcd可以用于实现mds高可用，没必要引入其他组件。 使用etcd实现元数据节点的leader主要依赖于它的两个核心机制: TTL和CAS。TTL(time server把MDS1注册过来的Key删掉© XXX Page 22 of 30 2. 1. 此时会有两件事情发生, 顺序不定： 一是MDS1定期去get Leader/MDS1失败后MDS退出 [事件1] 二是MDS2收到Leader/MDS1被删除，MDS2开始提供服务 [事件2] 如果事件1先发生，那么就是MDS1退出后，MDS2再当选为leader, 如果事件2先发生，那么就是MDS2当选为leader时，MDS1还在提供服务，

/A/C到/B/E symbolic link： hardlink：生成一个hardlink /B/E，指向文件/A/C list：遍历/A目录 5.1.2 好处 5.1.2 问题 5.2 分片方式二：Inode按照inodeid进行分片，Dentry按照parentid进行分片 rename：rename /A/C到/B/E hardlink：生成一个hardlink /B/E，指向文件/A/C 我们的文件系统定位是一个高性能的通用文件系统，元数据的缓存倾向于全缓存。 系统加载的时候从持久化介质中进行加载，需要把一条条持久化的记录加载到内存里。实现把string转化为inode结构体，再插入内存结构中。 场景二：业务运行过程中，元数据的增删改查。 如果采用raft的方式对元数据持久化进行保证，所有元数据的处理都是先写WAL，再修改内存结构。那么任何对元数据的增删改查，对应着一条记录，根据记录去修改内存数据。 400，查询"D"的inode信息。 5.1.2 好处 这种方案的好处在于，inode和dentry大概率落到一个分片上管理。在查询inode的过程中，第一步通过parentid和name查询inodeid，第二步通过inodeid查询inode结构体在同一个分片上处理。查询时，client只 需要向metaserver发送一次请求，就可以完成上面两步的查询任务。 5.1.2 问题 在一种特殊的情况下，可

Curve 分布式存储设计 程义 — Curve Maintainer XAgenda 第二 第三 第四 第一 Curve的由来 Curve的设计目标 Curve块存储 和 Curve文件存储 Curve社区Curve的由来 1. 代码复杂/代码量大 2. 运维难度高 3. 无法满足高的性能需求Curve的设计目标 1. Curve云原生软件定义存储 2. Curve块存储 说明Curve进展以及讨论 相关问题 6. 提交bug与建议：https://github.com/openCURVE/CURVE/issues 7. 参与Curve交流与讨论：微信群，右手边二维码Follow us! twitter.com/kubesphere kubesphere.io github.com/kubesphere UP/KubeSphere kubesphere

一个inodeid，然后根据这个inode id找到服务这个inode的分片。出于性能上的考虑的，client可以一次从mds获取一批inode，这批inode用完了之后，再去mds去申请。 思路二：client在创建inode的时候，自己选择一个分片，然后由这个分片自己分配一个inode。采用这种思路，在create fs的时候，就为fs准备好的几个copyset，然后client把copys set，就选定了服务的3个metaserver。至于均衡上，创建inode的时候，轮流在这个fs的copyset 上进行创建。这种方式肯定不如curve块设备的方案分配的那么均衡。 结论：采用思路二，由分片管理fs 3.2 copyset fs共用吗？ fs是否共用copyset，在实现上，只需要获取分片的时候把inodeid替换成fsid+inodeid的组合就行了。在获取inode和co

启动curvefs 问题1：root用户无法访问挂载目录 测试 allow_root 测试allow_other 参考文献 问题2：本地文件系统挂载默认是共享的？ 问题3：文件系统访问控制是在哪一层实现的？ 二、文件系统权限管理 文件类型 文件权限 特殊权限(SUID, SGID, STICKY) 文件默认权限umask 用户&用户组 文件系统用户权限管理 对mode的管理 对ACL（Access Control 结论：fuse挂载时使用'default_permissions' 和 ‘allow_other’ ；或者可以在用户态文件系统中自由的实现访问控制策略。 可以达到共享文件系统下的基于内核权限检查的文件访问控制 二、文件系统权限管理© XXX Page 16 of 33 // example in linux // --------- drwxr-xr-x 3 wanghai01 neteaseusers 4096

相对宽松10/17/22 13 PFS NVME读对齐实现 ●内存分配页面对齐，实现基于PRP严格的规定，这样SGL也可以用 ●第一个页面可以从非0的页内位置开始直到页面结束位置，必须是512字节倍数。 第 二个页面必须是整页，内存位置必须在页内位置0处。 最后一个页面，开始位置也在 页面0处，但可以是不完整的一个页面。 ●如上图所示，绿色位置是数据传输部分。 ●如果以iovec来表示： [page0+3584

3、改为O_DIRECT模式 How？ Why？新版本ChunkServer性能优化 1、模拟braft日志落盘方式的demo程序测试结果，latency为调用sync花费的时间（第一次新写，第二次覆盖写）; 2、因为在请求4KB的情况下，写入的大小带上头部后是4120，是不对齐的，所以又测试了一下把写入大小改成4096的情况：新版本ChunkServer性能优化 因此ChunkServe

client端配合完成。 空间分配 整体设计 分配器包括两层结构： 第一层用bitmap进行表示，每个bit标识其所对应的一块空间（以4MiB为例，具体大小可配置）是否分配出去。 第二层为free extent list，表示每个已分配的块，哪些仍然是空闲的（offset, length），以offset为key进行排序（这里可以用map或者btree对所有的free extent进行管理）。