MS_NOSUID|MS_NODEV, "allow_other,fd=9,rootmode=40000,"...) = 0 问题3：文件系统访问控制是在哪一层实现的？ 测试curvefs，发现文件系统链路默认是没有做权限控制。（挂载点mode 777） # mountpoint wanghai01@pubbeta1-nostest2:/tmp$ ls -l | grep fsmount drwxrwxrwx $ echo "world" >> file1 nbs@pubbeta1-nostest2:/tmp/fsmount$ cat file1 hello world 测试curvefs，发现文件系统链路默认是没有做权限控制。（ 挂载点mode 755）© XXX Page 8 of 33 wanghai01@pubbeta1-nostest2:/tmp$ ls -l | grep fsmount 1777（原因是设置STICKY，避免普通用户对非自己所属文件的删除） 3：这样达到的效果除了不支持ACL外与正常本地文件系统权限管理一致（一般情况下使用ACL极少，且从抓取的传媒接口调用发现并未涉及相关接口的调用）。 参考文献： https://www.huaweicloud.com/articles/0fe3750d1a5352b42911fdb96c6a8a47.html https://www

1 用UCX实现BRPC对RDMA的支持 徐逸锋2 BRPC简介 ●BRPC是Curve的基础通讯框架 ●支持远程过程调用 –C++ –TCP传输 –bthread协程(m:n调度，减少基于内核的下文切换 ，减少cache miss) ●多协议支持 –baidu_std,http,grpc… ●protobuf3 BRPC简介 ●Client/Server架构 ●使用Protobuf定义协议文件 ●Socket对象引用计数，多个Channel可以共享一个Socket对象 ●往SocketMap里调用Insert，要么返回已经存在的Socket对象（引用计数加一)，要么创建一 个新的12 BRPC EventDispatcher ●是socket事件分发的中心 ●使用epoll和边沿触发 ●提供监视一个fd是否可读写，并调用对应socket对象的成员函数1314 Socket 输入事件处理15 Socket 是socket文件句柄 –void (*on_edge_triggered_events)(Socket*) ●可读事件的回调函数16 Server创建Socket Listener 把系统调用创建的listen socket fd传给Socket::Create，获得一个Socket对象17 Socket Listener::OnNewConnections Listener 获得一个socket

PolarDB开发大赛: 230+参赛选手 21K+ 社区用户 • 全面开源 • 兼容PG&MySQL • 透明分布式 • HTAP • 企业特性(闪回、TDE、冷热分离...) 50+全链路伙伴: 韵达、莲子数据、网易数帆、 龙蜥、武汉大学 ... 等 需求 手段 需求 手段 需求 手段 需求 手段 需求 手段欢迎加入PolarDB开源生态

failover 情况下的加载时间 b. 扩展性/可用性/可靠性 扩展性不够，受限于单机的内存和磁盘，只能纵向扩展 可用性足够，由于是 master-slave 的方式，master 以同步方式调用 slave，slave 在内存中也缓存了全部元数据信息 master-slave 多副本数据 CurveFS 分布式元数据设计 类似 chubaofs 的元数据设计方式，同样是采用 dentry，inode 小文件可以共用 chunk 文件的目录数结构有单独的元数据节点存储 元数据包含两层映射，dentry，inode inode 在每个文件系统中是全局唯一的，inode 中包含文件的信息，包括用户，时间，软/硬链，数据分布等 元数据架构 元数据包含两个部分 卷的元数据管理 这部分 mds 已经实现。在上面架了一层文件系统后，卷信息中还需要包含文件系统元数据的路由信息 文件系统的元数据管理 需要记录 dentry，inode

高可用，克隆任务中断自动拉起继续克隆快照克隆服务器架构 • 基于brpc提供restful API的对外http接口 HttpService: • Serivce层面区分上层请求为同步接口调用，还是异步接口调用， 同步接口调用直接调用Core层接口实现功能，异步接口创建Task， 并交由TaskManager调度。 SnapshotService & CloneService: • 任务管理层负责调度 SnapshotTaskManager & CloneTaskManager: • 快照克隆核心模块，负责向下调用DataStore，MetaStore等底层 模块，实现快照和克隆的具体功能。 SnapshotCore & CloneCore:快照克隆服务器架构 • SnapshotDataStore负责管理快照转储的数据块，通过调用 S3Adaptor（一个封装了s3 client的接口层）与S3交互，存取s3 中的对象。 SnapshotDataStore: • SnapshotCloneMetaStore负责管理快照和克隆任务等元数据， 通过调用etcdclient，与etcd存储交互，存取etcd中的快照和克隆 元数据。 SnapshotCloneMetaStore: • CurveClient封装了Client接口，负责与MDS和ChunkServer交互。 CurveClient:

构，缓存之； 判断inode结构中，对应请求[off, size]位置的空间是否有分配：如果未分配或只有部分分配空间，则调用空间分配器分配空间，并根据空间分配器返回结果，修改inode结构（包括file length）; inode修改需要持久化到底层并修改本地cache； 调用curve client接口，写curve卷对应[offset，len] 数据。 （这里涉及到一个问题，是否从fuse （这里涉及到一个问题，是否从fuse下来的请求是4k对齐的，如果不是，那么这里还需要修改为read merge write，即读出未对齐缺少的部分，然后整个[offset,len] 调用curve client写）; 修改inode结构，如果上述区域存在先前未写过的区域，则需要去掉unwritten，具体方式根据inode结构而定；inode修改需要持久化到底层并修改本地cache；© XXX Page 6 of 11 read ip等信息，然后从metaserver获取inode结构，缓存之； 根据inode结构，拆分unwritten/未分配的区域与写过的区域，未写过的区域填0，其他区域继续读取 根据inode结构中信息，调用curve client接口，读取对应的[offset, len]数据。（这里同样要考虑4k对齐的问题，如果不对齐，则需要读取对齐的区域，然后去掉多读的部分）（读写可以做数据缓存， 当前先不考虑）。

*pathname, const struct open_how *how, size_t size); open系统调用会打开pathname指定的文件（如果不存在，如果携带O_CREAT flag则会创建），返回一个文件描述符fd（该fd是进程打开文件描述符表的index），在后续系统调用（read(2)、write(2)、lseek(2)、fcntl(2) etc.）中指向这个打开的文件。打开的文件描述符记录中保存着文件的offset files_struct 类型的 files 字段，里面有个保存了当前进程所有已打开文件 描述符的数组，而通过 fd 就可以找到具体的文件描述符:© XXX Page 3 of 23 open & openat 系统调用的区别：如果pathname是绝对路径，则dirfd参数没用。如果pathname是相对路径，并且dirfd的值不是AT_FDCWD，则pathname的参照物是相对于dirfd指向的目录，而不是进程的当前工作目录；反之，如 time（进程uid=文件uid或者进程在它的user namespace有CAP_FOWNER, 而文件的uid在这个namespace中有一个映射）。 O_NOATIME : 在进程执行exec系统调用时关闭此打开的文件描述符，防止父进程泄露打开的文件给子进程。 O_CLOEXEC O_PATH: 使用 O_PATH 将不会真正打开一个文件，而只是准备好该文件的文件描述符，而且如果使用该标志位的

use_reply_create时增加1 当内核移除其inode cache时，会调用forget，此时lookup count需要减nlookup（forget的参数） 当umount时，所有lookup count减至0 不应该完全依赖forget接口去实现inode的移除，因为forget接口可能不会被内核调用（例如client崩溃） 相关调研 moosefs moosefs 未对接forget 会崩溃，也可能下线了，永远不再起来。所以实际的内存和外存中的inode的删除机制，必须是在metaserver中实现的。client端只是 进行nlink-1的操作。 不能完全依赖forget接口的调用来移除inode，因为client可能会崩溃，也可能下线。所以实际移除inode只能依赖于metaserver，两种方式：chubaofs的简单粗暴放7天就删，或者moosefs使用session机 client端后续的open只在本地将open num++ client端在close过程中，首先会去open num–， 当发现open num==0时，也就是所有的open都已经close了，此时调用close on metaserver close on metaserver的过程，将移除内存中的session。© XXX Page 12 of 15© XXX Page 13 of 15

9 启动后台线程，将写Cache定时刷到S3上，同时通过inodeManager更新inode缓存中的s3InfoList。具体细节见 本地磁盘缓存 如果有配置writeBack dev，则会调用diskStroage进行本地磁盘write，最终写到s3则由diskStroage模块决定。 关键数据结构 message S3ChunkInfo { required uint64 chunkId 果没有则生成新的fileCacheManager，解锁，调用fileCacheManager的Write函数。 2.考虑到同一个client同一个文件同时只能一个线程进行文件写，所以在Write函数中加写锁。 3.根据请求offset，计算出对应的chunk index和chunkPos。将请求拆分成多个chunk的WriteChunk调用。 4.在WriteChunk内，根据index找到对应的 如果有可写的DataCache，则调用Write接口将数据合并到DataCache中； ，加入到ChunkCacheManager的Map中。 如果没有可写的DataCache则new一个 5.完成后返回成功。 Read流程 1.根据请求offset，计算出对应的chunk index和chunkPos。将请求拆分成多个chunk的ReadChunk调用。 2.在ReadChunk内，根据

1 基于SPDK的CurveBS PFS存储引擎10/17/22 2 Why ●为了减少使用cpu做内存copy，减少系统调用 ●发挥某些被操作系统屏蔽的功能，例如nvme write zero ●根据阿里《When Cloud Storage Meets RDMA》的说法 ●在100Gbps网络带宽时，内存带宽成为瓶颈 ●Intel Memory Latency Checker (MLC)测试得到的CPU内存带宽是 61Gbps10/17/22 3 RDMA可以减轻CPU负担 ●可以减少CPU操作网络通讯的开销 ●读写内存都由网卡进行offload ●应用程序不再通过系统调用在内核和用户态来回切换10/17/22 4 磁盘的读写 ●基于EXT4的存储引擎，依然需要通过系统调用来回切换 ●读写都需要CPU拷贝数据 ●不能发挥某些NVME的功能，例如write zero10/17/22 5 为什么用PFS ●对代码比较熟悉