com/cw123/curve/tree/fs_s3_joint_debugging 环境：test2 1. 启动curvefs 手动创建curve卷，/etc/curve/client.conf中配置卷所在集群信息。 启动服务&client挂载卷：bash startfs.sh start volume (挂载目录为/tmp/fsmount)© XXX Page 3 of 33 # wa allow-other'以允许相应用户有权访问该文件系统，如果挂载者不是root还需要在/etc/fuse.conf（/usr/local/etc/fuse.conf）中增加配置项“user_allow_other”（该配置项是无值的）。详见libfuse官方文 档：https://github.com/libfuse/libfuse#security-implications # The file fd 时的初始功能协商期间启用了 ACL 支持，则此挂载选项将被隐式激活。 在这种情况下，内核执行 ACL 和标准的 unix 权限检查 疑问：协商期间do_init()中的启用ACL的flags如何设置？ 初始化时的 通过 ： 功能协商 init()函数实现© XXX Page 9 of 33 // libfuse lib/fuse_lowlevel.c static void do_init(fuse_req_t

timeout设置 • OPEN 打开 inode返回ok • GETATTR 返回fstat • READ inode 读取的内容不等从16KB到128KB • 关闭⽂件时会发送FLUSH请求和RELEASE请求 • 场景2 解压压缩包场景 • LOOKUP inode 没有该inode • CREATE创建⽂件句柄并返回fstat + timeout设置 • WRITE WRITE 写⼊内容从0～16KB不等 • SETATTR inode 根据UID，ATIME，CTIME，length来设置属性 • 关闭⽂件时会发送FLUSH请求和RELEASE请求FUSE⽂件IO读写流程FUSE的IO路径及瓶颈分析 • 对⽐测试 • ⽂件访问测试直接访问ext4 • 通过FUSE访问passthrough_ll底层ext4 • 内核调⽤延迟测试 • 与FUSE 相关⼯作 • extFUSE • google android12 passthrough什么是eBPF • ebpf是不同环境下内核配置， 调试，监控⼯具 • map映射 • 验证器 • Hook • Helper api配置TCP Initial RTO • 场景 内核4.12之前 initial RTO是⼀个常数1s • 应⽤类型BPF_PROG_TYPE_SOCK_OPS

开源项目 ●支持RDMA，TCP，Shared memory等 ●能透明支持多个链路传输，例如多网卡bond ●编译成.so或lib的方式，可以集成到应用程序里 ●有完善的配置功能，ucx_info可以dump配置信息 ●有性能测试工具 ●比较详细的文档2223 UCS ●是一些工具代码，例如 –链表 –hash table –epoll event loop – memory 命令行参数控制context的属性 ●--brpc_ucp_error_mode缺省是none，是的本地通讯使用shared memory成为可能 ●--brpc_set_cpu_latency 非-1, 设置intel cpu节电模式，可能减少硬 件延迟。 –/dev/cpu_dma_latency ●root特权 –Busy poll下不要开启，可能导致电耗过高、cpu降速40 Ucp Worker –UCX的地址依然是tcp地址。5758 修改 Socket Connect59 修改Socket Connect60 修改Socket::DoRead ●UcpWorker在接收到ucp_ep上的断开事件时，设置UcpConnection处于Error 状态，再调 用UcpConnection::DataReady，进而调用Socket::StartInputEvent ●UcpConnection的Re

，然后从metaserver获取denty（这里有两种方式，一种是只获取当前需要的 denty，一种是list整个目录的denty，这个需要考虑用哪个接口） 根据找到的denty结构，获取inodeid，设置 fuse_entry_param，返回给fuse write void (*write) (fuse_req_t req, fuse_ino_t ino, const char *buf, size_t int to_set, struct fuse_file_info *fi); 根据inode id 找到inode id 对应的inode 结构（从缓存或者metaserver） 根据to_set字段设置相应的attr字段，然后持久化到metaserver，并更新本地缓存。 access 可先不支持，返回ENOSYS rename void (*rename) (fuse_req_t req etaserver的ip就可以） 与mds 交互，调用mds接口获取metaserver copyset 和 topo信息，这部分可先不实现（目前先支持单metaserver的情况下，可先不实现，由配置文件加载metaserver的ip） 与metaserver交互, 调用meta server接口获取文件系统元数据信息，调用meta server接口获取文件和目录信息等 与现有块设备client交互，调用块设备接口，对卷进行读写。

sustained机制/reserve机制 当一个trashtime等于0的TYPE_FILE类型的文件被一个客户端正在打开，而同时有另一个客户端要删除它时，此时master对该文件节点的处理是并不立即删除该文件而是设置为TYPE_RESERVED类型并将该fsn ode连接到reserved链表中，使该文件虽然已经从文件树中删除掉，但因为另一个正在打开该文件的客户端因为持有该节点inodeid,所以不影响它对该文 ， metaserver在收到该请求后，则设置inode的DeleteMarkFlag，并将其放入freelist。 freelist在定期清理时，当发现设置了DeleteMarkFlag，则直接从inode tree和free list中移除该inode，不再等待7天。 chubaofs实现了强制从freelist中移除inode的机制，同样是使用设置DeleteMarkFlag的方式。 chu 方式记录nlink==0的inode id， inode结构保存在原地，进入trash时记录进入trash的时间。 trash需要定期扫描freelist中的inode id， 当发现 大于7天（可配置）时，将inode清理，同时删除相关数据（s3上和卷上的）。 inode没有被打开已经进入trash时间 trash中需要区分inode是否被打开，以帮助工具在查询时，展示inode进入trash

但同时只有一个mds节点提供服务，称该提供服务的mds节点为主，等待节点为备；主节点的服务挂掉之后，备节点能启动服务，尽量减小服务中断的时间。 需要解决的问题就是：如何确定主备节点。 2. 技术选型 提供配置共享和服务发现的系统比较多，其中最为大家熟知的就是zookeeper和etcd, 考虑当前系统中mds有两个外部依赖模块，一是mysql， 用于存储集群拓扑的相关信息；二是etcd，用于存储文件的元 而etcd可以用于实现mds高可用，没必要引入其他组件。 使用etcd实现元数据节点的leader主要依赖于它的两个核心机制: TTL和CAS。TTL(time to live)指的是给一个key设置一个有效期，到期后key会被自动删掉。这在很多分布式锁的实现上都会用到，可以保证锁的实时性和有效性。CAS(Atomic Compare-and-Swap)指的是在对key进行赋值的时候，客户端需要 GetTimeout ③使用Observe监控指定前缀的key的最小版本的变化情况。© XXX Page 19 of 30 1. 2. 1. 该部分涉及到的参数说明： 参数 说明 当前配置 ElectionTimeout etcd集群leader选举的超时时间 3s LeaseTime mds当选leader之后，与etcd集群维持租约的过期时间 租约的keepalive间隔为LeaseTime/3

inode 若源节点类型为TYPE_SYMLINK，重新设置目的节点与源节点保持一致 不存在 创建新的dentry 若源节点type= TYPE_DIRECTORY，递归创建源节点目录下的所有子文件进行快照 若源节点type= TYPE_FILE，则设置length、chunks使其与源节点的对应属性一致 若源节点类型为TYPE_SYMLINK，设置目的节点的path与源节点保持一致 为 dentry 4k，以一个20TB的盘为例： blk=4k, 需要bitmap的大小为640MB blk=64k, 需要bitmap的大小为40MB 在设计过程中，对于每个文件系统，blk应该是可以根据业务形态来配置的 bitmap重建时间？ 如果通过获取所有inode，重建出当前的空间分配情况，我们常见的业务形态有以下两种： ① 在AI训练等场景，文件的目录层级较少，文件数量较多，文件较小。这种情况inode

dump) }; Q&A© XXX Page 9 of 12 单靠 redis 的 AOF 机制能否保证数据不丢失? 不能，因为 AOF 与 SET/DEL 这些操作不是同步进行的，即使刷入文件配置项 开启最高级别的 always 选项，也有可能丢失一个事件循环的数据，实现如下： appendfsync // : call(...) // propagate(...) c/feedAppendOnlyFile) (2) 文件写入: 将 AOF 缓冲区的内容以 append 方式写入文件 (详见: aof.c/flushAppendOnlyFile) (3) 文件同步: 根据 appendfsync 配置选项决定文件同步频率, 该步骤与步骤 2 紧密关联 (详见: aof.c/flushAppendOnlyFile)© XXX Page 10 of 12 1. 所以，AOF 不能保证数据 100% 哈希表渐进式 rehash 的详细步骤： (1) 为 ht[1] 分配空间, 让字典同时持有 ht[0] 和 ht[1] 两个哈希表 (2) 在字典中维持一个索引计数器变量 rehashidx, 并将它的值设置为 0, 表示 rehash 工作正式开始 (3) 在 rehash 进行期间, 每次对字典执行添加、删除、查找或者更新操作时, 程序除了执行指定的操作以外, 还会顺带将 ht[0] 哈希表在 rehashidx

odeId的目的是为了后续从对象存储上遍历，反查文件，这里就要求inodeId是永远不可重复。 读写缓存分离 读写缓存的设计采用的是读写缓存分离的方案。 写缓存一旦flush即释放，读缓存采用可设置的策略进行淘汰（默认LRU），对于小io进行block级别的预读。 即读写缓存相互没影响不相关， 缓存层级 缓存层级分为fs->file->chunk->datacache 4层，通过inode 后台刷数据线程© XXX Page 4 of 9 启动后台线程，将写Cache定时刷到S3上，同时通过inodeManager更新inode缓存中的s3InfoList。具体细节见 本地磁盘缓存 如果有配置writeBack dev，则会调用diskStroage进行本地磁盘write，最终写到s3则由diskStroage模块决定。 关键数据结构 message S3ChunkInfo {

DELAY会使I/O 函数马上返回0，但这又衍生出一个问题，因为读取到文件末尾(EOF)时返回的也是0，这样无法区分是哪种情况。因此O_NONBLOCK就产生出来，它在读取不到数据时会回传-1，并且设置errno为EAGAIN。 : 每次write都等到物理I/O完成，包括write引起的文件属性的更新。 O_SYNC O_DSYNC: 每次write都等待物理I/O完成，但是如果写操作不影响 aaa I/O模式类 O_DIRECT, O_SYNC, O_DSYNC, FASYNC, O_NONBLOCK(O_NDELAY )，这类flags应该是内核进行了支持，在用户态文件系统中进行相应设置，例如O_DIRECT有具体的文档描述说明了这一点，其他flag暂时查阅资料和 代码还未发现正面说明。 O_DIRECT© XXX Page 17 of 23 一般来说，当调用 open() 系统调用打开文件时，如果不指定 测试结果：基于curvefs测试结果不符合预期：在fuse_reply_open中设置fi→direct_io，从日志也看到设置成功，但是 ，所以猜测要么没有真正 在不进行对齐的情况下本地文件系统会报错，但是curvefs没有报错 启用成功，要么fuse做了处理。 分析结果：用户态文件系统在fuse_reply_open中设置fuse_file_info→direct_io后，内核感知该flag避免使