GlusterFS探究(一): dht,afr,fuse, mgmt 层 几个问题总结
0， 跟踪学习 在dht层实现 的 rebalance 操作
a， 在目录上记录 layout范围的结果，
i, mkdir (只在mkdir时刻) 会 有一个 layout对象，除了 start_off 和 stop_off 其他值都可以填充；
而其他值的填充 必须继续往下走。
ii, dht_layout 读写 disk ? ? 客户端第一次 读时 会恢复到mem？？？ （where?）
iii，目录是 无 拓扑关系； /dir1/dir2 是两个目录, 分别为 /dir1 和 /dir1/dir2两个；
b, dht_layout_search （用 (path + filename)来计算，并在上级 目录的 ctx里 寻找 对应的访问，然后 确定 哪一个brick通信）；
c， dht_subvol_get_cached /dht_subvol_get_hashed (cached 指最早加入的 brick 对应的client端！！)
d, 可能是因为brick里数据量太少，导致rebalance操作一直没发生 拷贝数据的现象，所以先暂停一下。
1，跟踪学习 replace-brick 操作的实现
比如 命令
gluster volume replace-brick test 172.16.30.185:/sam6 172.16.30.185:/sam7 start force
也就是用本机的 /sam7 代替 /sam6。
a, 当glusterd 进程 处理这个命令时，会修改 /sam6对应brick进程的配置文件，在 features/index 添加一个子xlator , 就是
cluster/pump -> protocol/client, 充当拷贝数据的客户端。（设为进程A ）
另外， 会生成一个 以protocol/server ->features/locks->storage/posix 为配置文件，生成一个 新glusterfs进程，
作为实现replace-brick功能的临时进程。（设为进程B ）
b, 实际的拷贝数据 是 这两个 进程 在socket.c 中 __socket_rwv函数中实现，
A 进程 会打开在原来 brick 上的 老文件，并读取，再写到 对B 的套接字里。
B 进程 不断接受从A来的数据，并且在新的 brick中创建同样的文件。
c, 具体实现 实在 进程B，会从 老brick上获取每个文件gfid， 并在新brick的 /sam7中查找，因为查找不到，
就会导致 cluster/afr层的self-heal
至于 cluster/afr 层 具体的 self-heal 的过程还得再跟踪下日志和代码。
d, replace-brick操作 在gdb跟进程时，只要有耽误，数据就不会再被拷贝，重启服务也不行，只能清理环境，重新再来一遍。
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
1, cluster/afr 层 selfheal 过程实现
比如 命令
gluster volume replace-brick test 172.16.30.185:/sam6 172.16.30.185:/sam7 start force
老brick 对应进程设为 A ， 新 的临时 rb进程设为B。
a, 过程可能是：
进程B从进程A获取在A上所有 文件和目录的gfid, 然后将 /sam7看作是一个与/sam6互为镜像的brick。而此时它刚刚online, 在上面执行lookup.
而 cluster/afr 实现机制，发现 /sam7上 任何一个文件有问题，就会从 /sam6上 拷贝一个文件 覆盖替换掉 /sam6上同名文件。
（大致过程应该是这样的，而是 还得有更仔细的分析日志的验证。 想法可以有，但是验证需要不少时间。 ）
b, 从调用 afr_launch_self_heal 函数进入 selfheal过程。（应该是features/index 层调用这个函数）
流程大概是： 1，从副本中找到一个能用的 brick对应的xlator;
2, 修复 父亲目录；
3， 修复 entry
4, 修复 metadata
5, 修复 data
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1, dht 层 每个目录的 layout信息 是否 保存 到集群的对应目录扩展属性上
因为挂载的客户端毕竟是多变的，而每个目录的layout信息显然 非常重要。
分析了一下代码， 每个目录的inode的 inode_ctx 中保存的是layout数据，对它的操作也只是在内存中，并没有跟对应brick发起通信。
这个是否可靠？还是因为对应的代码没找到？
实验：清空所有日志，在 /mnt 下创建一个目录，来分析整个过程。
分析了storage/posix代码和日志，发现 服务器端实际上只是在对应目录的扩展属性里记录了gfid, （按照设计，这个gfid 包含了 根目录的路径前缀）。并 没有记录 layout信息。
结论： 每个目录layout信息确实只在客户端内存里，与服务器端无关。
layout信息中缓存的是last 在目录下动作（如本身创建，目录下建立文件等，不包括创建子目录）以来，在本卷中各个brick的可用状态。 如果出现某个brick DOWN情况，这样这个目录的layout信息就是有问题的，它会临时把 新文件创建到 临时的brick上。但是过一段时间，会进行 self-heal，即 在 brick 全UP 情况下 应该在的brick上创建链接文件。以待以后来rebalance .
2, 修改了日后实现 （）
a, 每条日志头上增加一个序列号，方便分清楚次序。
b, 对最核心的xlator_fops中 各个函数，建立了 fopslog 日志，只记录 它的名字和序列号。
c, （将做 ）按照 各个 进程 建立目录，所有的日志落在这个目录下。
3，iatt gfid stat 信息
iatt 信息是 glusterfs自己定义的 文件属性信息的结构，它主要是posix的 stat结构（时间增加了微妙部分），和 gfid.
gfid 是 整个集群里的 inode-number, 唯一标志了一个文件和目录。
在posix层 最重要的是 通过系统调用 fstat(取stat) 和 lgetxattr （取gfid）, 来构造 一个 iatt 或者将新的iatt落盘（实际上只有gfid）.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1, Gluster 使用 fuse 实现挂载功能
a, { ls -l } => kernel => fuse-k => fuse-u => glfs-graph
fuse-u实现 命令行的功能， 即来自fuse-k解析的请求. (这一切 在 fuse-loop大循环中完成， 其监听fd,处理请求)
线程 B： 死循环中，平时一直监听/dev/fuse 的fd, 有task时被唤醒，走graph流程来处理请求。（A， A-cbk 阻塞在哪里？）
线程 A： 解析请求，并且 添加 task， 并且 最终把数据按照 fuse spec 格式 写到 /dev/fuse 打开的fd 中去。
Gluster里fuse相关代码是 fuse-u 相关实现部分，也就是，当标准命令行处理gluster里面的数据时的实现。
由于客户端只会启动一个进程，而且在挂载点操作很方便，这样就方便了复现和调试 。
另外，标准命令行实现是由coreutils库来实现的。通常每个命令都是依次调用几个系统调用函数，将取得的结果返回给客户。
使用GDB 跟挂载的进程，能很轻松的跟踪到 每个命令实现时，实际上调用了那些的posix标准函数。
b, fuse: fuse_attr
glfs: iatt
posix: stat
这三个结构是三个系统中定义的元数据相关的核心数据结构。非常核心的功能实现时将这些数据结构互相转换。
c, 实现挂载功能时，fuse成为一个xlator, 并且在被画在客户端graph上。
在 客户端进程的核心结构上， 一般是 fuse xlator作为功能栈的 链表头节点。
当阻塞在 readv系统调用上的 fuse xlator 线程B 接受到内核数据后，按照 fuse 标准格式 会解析 OPCODE，它们是posix标准的接口
操作码。然后 会验证数据，在有必要时 会执行 STACK_WIND，将调用请求按照功能栈向下面调用，最终是Gluster来处理的请求。
还需解决问题， i, 挂载时端口映射问题； ii, syncop 做的什么。iii，fuse 层缓存数据了么？ iiii， inode 是 独立的一份数据，而每个
xlator只是 借用了 唯一的 inode地址来 ctx ？
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1， gd_svc_cli_actors 这个 是在哪里起作用的？
这是个struct数组。而这个struct有个成员为函数，在这个函数中会最终调用glusterd_op_begin_synctask
(里面实作是gd_sync_task_begin)
而这个整体 和 gd_svc_peer_prog, gd_svc_cli_prog, gd_svc_mgmt_prog,
gluster_pmap_prog, gluster_handshake_prog, glusterd_mgmt_hndsk_prog,
这些个整体被 glusterd_program_register 加载到 glusterd 地址空间中来执行。
2， 这个流程在 gd_sync_task_begin 函数中确定好了。
a， glusterd_lock
b， glusterd_op_set_op
c， gd_build_peers_list
d， gd_lock_op_phase
e， glusterd_op_build_payload
//往glusterd进程的一个成员dict添加了一个值，下面流程会用到。
//哪个dict ?? 栈上构造的临时空容器，会按后面的需要采集glusterd维护的数据信息。
f，gd_stage_op_phase
g， gd_brick_op_phase
h， gd_commit_op_phase
这些流程中 的每一般 对会按照 op 分别调用不同的函数。在处理结束后，会更新 glusterd保存的元数据信息。
3，一个dict指针打天下 不断处理会更新其中某些 key 对应的value.
任何操作都会需要一些glusterd进程缓存的信息，dict会事先采集这些信息，而这个本身也充当对 操作的validate。
4, 返回给命令行的结果 是在rpc-xdr来实现，按照xdr标准格式解析请求，再将结果按标准格式返回给gluster命令行进程。
最好能够 多 用GDB跟踪一下glusterd进程，熟悉很多的接口。