work flow

[cocalele]

工作全流程

1. pfs初始化 对于共享盘，在配置文件里面以配置shared=1表示，比如：

   [tray.0]
   dev = /dev/sdf
   shared=1

   pfs首先检查是否为新盘，如果是，则按照下面步骤对盘进行初始化。初始化也即创建初始磁盘元数据，元数据布局按issue: disk layout 的描述进行。 1) 判断盘是否为新盘，如果是： a. 获取global meta lock b. 再次判断盘是否为新盘，如果已经被其他节点初始化了，则结束初始化 c. 初始化global meta d. 释放global meta lock

mkfs.pfs2命令 盘可以是动态加入的，mkfs.pfs2命令就起到这个作用。这个命令执行时通知本机的store服务，把指定的盘加入到集群。 加入集群的盘在服务下次启动时应该能自动加入。因此需要动态需要对配置文件进行自动修改。 pureflash现在使用的配置文件是ini格式，不提供通过代码进行动态修改的方法。【实现不了就需要运维人员修改配置文件】

启动一个线程作为owner线程？

2. 向zk注册共享盘，注册写入的信息包括2部分，1） 自己的store_id，以声称自己和这个盘的联接关系 2） owner 锁，以竞争这个盘的owner

        /cluster1/shared_disks/
                        + <disk1_uuid>
                               + <store1_id>
                               + <store2_id>
                               + owner_store
                                        + <ephemeral_node1 := store_id>
                                        + <ephemeral_node2 := store_id>

3. 创建volume/file 通过pfcli创建volume，引入一个新的命令conductor op: pfs2_create_file，参数包括file_name, size 这里没有指定disk相关信息，

4. open file 客户端需要向conductor发请求打开pfs2文件，这个像普通的volume一样。但是具体操作上有区别

   1) 使用open_pfs2 命令（是否有必要？ conductor通过元数据可以判断是普通的volume还是pfs2 file） 2) conductor返回的内容不是普通volume open的内容，而是prepare volume时向store发送的volume信息。这是为了在client端实现IO的下发，client需要知道每个shard的具体信息，主要是disk uuid 以及 盘符。（client按照盘符打开盘后，要比较uuid是否符合预期）

5. IO 流程 为了在client将IO直接下发到共享盘，而不是经过store服务转发，需要将Pfs进程中PfFlashStore， PfIoEngine 这两个类以及相关依赖复制到client代码。 然后在PfClientVolume::process_event函数中处理EVT_IO_REQ事件时将IO请求发送给PfFlashStore。这里的挑战比较大，server端用的数据结构（比如PfServerIocb)和client差异很大。

6. 元数据修改流程 元数据修改需要远程调用owner节点完成。网络请求可以有两个发送方法： 1) pfs里的慢速通道，通过HTTP请求完成。慢速通道是同步调用，编码容易。 2) pfs里的快速通道，通过IO请求完成，定义新的IO opcode。快速通道是异步调用 通常在用户IO 过程中只会发生block allocation元数据请求。

delete block的操作发生在delete snapshot, delete volume的时候。这些请求由pfconductor发送，而不是client。

client watch zk上的owner_store节点，以获知owner的变化。

delete block的操作发生在delete snapshot, delete volume的时候。这些请求由pfconductor发送，而不是client。

7. create_snapshot 原来的逻辑创建快照时由conductor把meta_ver推送给store。现在没有store参与IO流程。 共享盘（RAC场景）不支持快照，thick provision ，只考虑单节点挂载pfs2文件。create snapshot把请求发给client，conductor。 client如何向client(qemu)发命令？

8. delete volume/snapshot 执行delete操作的时候，client进程可能已经不存在，必须由owner节点执行 lmt修改， trim。 如果client存在，删掉某个block后，需要client更新自己内存里的LMT。这种情况下，通知client，然后由client通知conductor去删除比较好。 client还是需要一个接受通知的能力！以及cli发现client的能力！

9. client注册机制 以volume为粒度，哪个client在访问哪个volume。可以使用zk进行注册

[qiyuanzhi]

创建volume/file 通过pfcli创建volume，引入一个新的命令conductor op: pfs2_create_file，参数包括file_name, size 这里没有指定disk相关信息

多共享盘时，pfs2_create_file 是不是需要支持指定disk，以说明当前的这个file是在哪个共享盘上创建的？

[qiyuanzhi]

元数据修改需要远程调用owner节点完成

除了元数据的修改需要请求owner之外，在client open volume时：

1）通过conductor拿到了shard相关的信息；

2）需要通过owner 拿到已经存在的lmt信息，这个也需要放到 慢速通道 或者 快速通道中去实现；

[qiyuanzhi]

添加一个图示

[qiyuanzhi]

client和server之间LMT一致性的维护： 可以通过client和conductor之间建立长链接，通过message push的方式实现； 例如快照的实现： 1）client向conductor建立链接时，给conductor发送一个message，等待message的返回； 2）conductor维护volume和connection的关系表，当对volume创建ss时，将带有ss的message回复给client，并等待client补充新的message； 3）client接受到新的ss后，将新的message补充到conductor；且后续IO会进行cow； 4）conductor接受到补充message后，快照创建成功；否则，快照创建失败；（此时即使快照创建失败，但是client更新ss成功，也只是会造成垃圾数据）

其他的关于meta ver的修改，遵循上面的原则。

client和conductor通过例如心跳的机制维护长链接，长链接断开，影响管理路径（快照，删除等）操作，不影响IO路径操作。

[cocalele]

状态更新：在pfs2分支，952ca9c 这个版本，已经完成了基本IO，可以运行pfdd进行数据写入