接上期，
PolarFS 主要由两层组成，一层是存储管理层，上面一层是文件系统元数据和提供文件系统API层，存储层负责所有节点的磁盘资源，并为每个数据库实例提供数据库卷。文件系统层在此基础上提供文件管理，负责文件系统元数据并发访问的互斥。
下图为展示POLARFS 集群中的主要组件，libpfs是一个用户控件文件系统实现的连接库，具有一组类似的posix文件系统API，连接到POLARDB进程，Polarswitch驻留在计算节点上，用于将将应用程序的I/O请求重定向到chunkserver ，chunkserver部署在存储节点上用于，处理I/O请求，POLARCTRL是控制面板，包括一组在微服务中实现的主节点，以及部署在所有计算和存储节点上的代理，Polarctrol使用mysql 事例作为元数据存储库。
3.1 文件系统层
文件系统层提供了一个共享和并行的文件系统，用来同时访问多个数据库节点，举例假设POLARDB 中的主节点正在创建表，此时就会在POLARFS上创建一个新的文件。执行select 语句在只读节点访问文件，因此因此需要去同步修改文件系统的元数据到从节点，保证数据的一致性避免元数据被损坏。
上图是libpfs 接口部分代码
3.1.1 libpfs
libpfs 是完全运行在用户空间的轻量级文件系统，上图中提供了一组类似posix 文件系统的API，所以将数据库移植到PolarFS之上是非常容易的。
当数据库启动开始，pfs_mount 加载到卷初始化文件系统的状态，卷标的名字是全局卷标识符，并将其分配给polardb 的实例，同时主机的ID也是供磁盘paxos卷逻辑的唯一标志数据库节点，在加载的过程中，libpfs 从卷标中加载文件系统元数据并且构造相关的数据结构，在主存中存储对表文件进行文件进行文件迎神和块映射表。
在数据库销毁的过程中，pfs_mount会卸载卷相关的资源，在卷空间增长中，pfs_mount_growfs 会分配可用的块文件给数据库进行扩展，Rest 函数等价于posix中的API 的功能。
3.2 存储层
存储层提供管理和访问文件系统的文件系统的作用，卷被分配给每一个数据库实例，并且挂载这chunks。卷的容量在10GB到100TB之间可以满足巨量数据库的使用的需求，并可以添加卷满足扩展需求。卷能够被随机访问读或写在512B，和传统的存储设备一致，在同一个chunk中修改的数据的操作是原子性的。
Chunk
一个卷中的chunks 被拆分到chunkServer中，一个chunk是分布式数据最小的单元。单个chunk是不会跨盘存储的，并且他会复制到三个不同的chunkserver 上，同时chunks 可以合并但需要在没有热点存在的基础上。
在POLARFS 中chunk 被设置为10GB这比其他系统中的单元要大的多，64MB chunk通常被用于GFS，这样的方式降低了元数据管理的压力，举例100TB 的卷消耗了10000条记录在元数据库中，因此所有的元数据能够在POLARSWITCH 的主存中被cache. 因此避免了额外的元数据访问的造成的额外的I/O 路径访问。
这样的设计本身也有一些问题，热点 chuck是无法被分割的，但基于数据块可以合并和数据块和数据库实例之间的比例（1000：1），POLARFS 可以达到整体系统性能得平衡。
Block
一个 chunk 被进一步划分通过blocks在chunkserver中，并且每一个block 被设置成 64KB，一个10GB 的chunk 包含163840 数据blocks，逻辑块地址范围在0到10GB，这些被存储在chunk server中，每个磁盘上空闲块的位图。单个chunk的映射表占用640kb内存，这样的存储容量可以缓存在ChunkServer的内存中。
3.2.1 polarswitch
PolarSwitch是一个部署在数据库服务器上的守护进程，同一个或多个数据库实例一起部署。在每个数据库进程中，libpfs将I/O请求转发到
PolarSwitch守护进程。每个请求都包含寻址信息，如卷标识符、偏移量和长度，可以来识别相关的块。I/O请求可能跨越多个块，在这种情况下，请求分成多个子请求。最后，一个元素请求被发送到chunk的leader所在的ChunkServer分成多个子请求。最后，一个元素请求被发送到chunk的leader所在的ChunkServer。
通过查找本地元数据缓存(与PolarCtrl同步)，PolarSwitch找到属于一个块的所有副本的位置。一个块的副本形成一个共识组，一个是leader，其他的是follower。只有leader可以回答I/O请求。共识组中的领导变化也会同步并缓存在PolarSwitch的本地缓存中。如果发生响应超时，在检测leader选举是否发生时，PolarSwitch不断重新尝试，发生问题则切换到新的leader并立即重传。
3.2.3 chunkServer
chunkServer 部署在存储服务器上，多个chunckserver进程运行在存储服务器上，每个存储服务器有自己的标准的NVMe SSD ，并且他绑定到标准的CPU，两个chunkserver 是不对资源进行共享使用的，chunkserver 负责存储块并随机访问chunk，每个chunk包含一个write ahone log (WAL)日志，为了保证数据的在chunk中改变后的原子性和持久性。chunkserver 采用一块固定尺寸的3D xpoint ssd 作为wal 日志的缓存。如果数据写满后，将回收空间，如果还没有足够的空间日志将写到NVMe SSD 作为替代。
chunkserver 中使用并行协议，相互复制IO数据形成一个组，一个chunkserver如果因为各种问题脱离了组，基于网络或者临时的问题引起的错误，或者网络临时不可达，或者服务器升级或重启，在针对这些情况下，最好的方式是等待失联的chunkserver 在此回归重新加入到组中。在其他的事例中如果是长期的失败，将会引发chunkserver 迁移到其他的服务器上，并且需要满足足够数量的副本。
断开连接的chunkserver 会尽量尝试在加入到原有的组，如果时间超过预先的设定，则polarctrl 会做出其他的措施，其中会对比出现问题之前的chunkserver 的列表，并标注 chunckserver 永久性故障，但这个问题在某些时候，难以做出决定。举例，一个 chunkserver中存在一个慢速的磁盘，有很长的延迟，但是却一直能进行响应，所以基于关键部件的机器学习对解决这个问题有很大的帮助。
