daos

category/checksum_and_scrub

@@ -0,0 +1,81 @@
+校验和清理
+介绍, https://daosio.atlassian.net/wiki/spaces/DC/pages/11223695379/Checksum+Scrubbing
+校验和清理器是一项后台任务，它扫描版本对象存储 (VOS) 树，以使用存储在 DAOS 服务器上的校验和来验证数据完整性。当检测到腐败时可以采取纠正措施。
+清理的数据是用户数据（使用 daos_obj_update 创建），而不是元数据，尽管元数据（VOS 树）用于扫描/迭代用户数据。
+设计概述
+后台任务
+每个将迭代容器的池目标 ULT。如果启用了校验和和清理器，则迭代对象树。如果记录值（SV 或数组）未标记为已损坏，则进行扫描。
+获取数据
+计算数据的校验和
+将计算出的校验和与存储的校验和进行比较。如果它们不匹配，则已检测到静默数据损坏
+无声数据损坏
+当检测到静默数据损坏时，将采取以下操作：
+将记录标记为损坏
+使用 DAOS RAS 通知系统引发事件
+增加校验和错误计数器
+如果达到了可配置的损坏阈值，则启动重建/排空操作
+用户界面
+交互模式（很高兴拥有）
+用于从脚本开始清理的 dmg 命令（仅运行一次，然后退出）
+校验和清理属性
+这些属性可以在 DAOS 系统级别（控制平面仍然需要此功能）或单个池级别设置。如果两者都设置，池配置将覆盖系统配置。更新后，它们应该立即处于活动状态，而不是等待处理完整的清理。例如，如果模式更改为更加激进，那么它应该立即变得更加激进（基于模式配置），而不是在下一次扫描中。
+池清理器模式(scrub) - 清理器如何针对每个池目标运行。容器配置可以禁用容器的清理，但不能更改模式。
+惰性 - 仅在系统空闲时运行（无 IO 活动且无空间压力）
+定时 - 定期运行，无论 IO 活动如何，但不要超过最大影响
+池清理器频率(scrub-freq) - 清理器校验和的频率。校验和的清理频率不应高于此属性，但是，根据清理器模式，它们的清理频率可能会较低。它在内部存储为秒数，但 dmg 应该通过接受分钟、小时、天、周来更加用户友好。
+池清理器最大 CPU 影响(scrub-max) - （未实现）如果存在其他 IO 活动，服务器调度程序用于运行清理器的 CPU 百分比。
+清理阈值(scrub-thresh) - 池目标被逐出时的校验和错误数。值为 0 禁用自动驱逐
+创建启用清理功能的池的命令可能如下所示：
+dmg pool create --scm-size 1G --properties=scrub:lazy,scrub-freq:1w
+# or
+dmg pool create --scm-size 1G aPool
+dmg pool set-prop aPool --properties=scrub:3,scrub-freq:1w
+容器属性 (-> doc/user/container.md)
+容器禁用清理- 如果为池启用了清理，则容器可以自行禁用它。
+池查询（未实现）
+在池查询中包含清理器信息。（DAOS-7680）
+校验和清理器数量/估计剩余数量
+上次全池扫描已完成（最大池目标完成情况）
+遥测
+收集并报告以下遥测指标，以便更好地了解洗涤器的运行情况。它们将在池和容器级别收集，但洗涤器 ULT Start 除外。
+日程
+Scrubber ULT Start - 洗涤器服务启动的日期时间
+Scrubber Current Start - 当前清理作业开始的日期时间
+洗涤器上次完成 - 上次洗涤作业完成的日期时间
+最后持续时间 - 最后一个洗涤器完成运行所需的时间。
+校验和计算计数
+校验和总数 - 在洗涤器的使用寿命期间计算的校验和总数。
+上次校验和计数 - 上次清理器作业期间计算的校验和数量
+当前校验和计数 - 迄今为止为当前清理器作业计算的校验和数量
+无声数据损坏很重要
+静默数据损坏总数 - 清理对象值时发现的静默数据损坏总数。
+当前静默数据损坏 - 当前清理器作业迄今为止发现的静默数据损坏数量
+设计细节与实施
+
+池超低温
+池 ULT 的代码可在 中找到srv_pool_scrub.c。这可能有点难以理解，因为由于 ULT 和 vos_iterator 工作方式的性质，存在多层回调函数，但该文件的组织方式使得函数通常调用其上面的函数（直接或间接作为回调） ）。例如（~>是间接调用，->是直接调用）：
+ds_start_scrubbing_ult ~> scrubbing_ult -> scrub_pool ~> cont_iter_scrub_cb ->
+    scrub_cont ~> obj_iter_scrub_cb ...
+相关页面
+中间件一致性
+中间件一致性
+DAOS 社区
+经常一起读书
+蠕虫功能
+蠕虫功能
+DAOS 社区
+页面树图标
+一起组织
+互操作性/{上/下}等级
+互操作性/{上/下}等级
+DAOS 社区
+经常一起读书
+成为第一个添加反应的人
+2页评论
+凯文·哈姆斯
+2022 年 9 月 29 日
+如果能够在全局 DAOS 设置中控制 Scrub Mode/Freq/Impact，那就太好了。举个例子，假设有一个存储“事件”，管理员希望在维护活动期间执行全面清理，他们会希望启动清理以使用所有 I/O 周期。
+瑞安·詹森
+2022 年 9 月 30 日
+注意到……我们确实计划将这些属性更改为系统范围与特定于池的属性。:slight_smile: 
+

category/daos

@@ -0,0 +1,84 @@
+---------------------------------------- DL ----------------------------------------
+引擎可扩展性加强, https://daosio.atlassian.net/wiki/spaces/DC/pages/11442552865/DAOS+engine+scalability+improvements
+DAOS 存储集群应该能够扩展到数千个存储服务器并处理来自数百万个客户端进程的 I/O 请求。DAOS使用的所有分布式协议都可以支持这种级别的可扩展性，但是，从软件设计和实现的角度来看，如果引擎侧没有资源控制，不断地向所有引擎的所有目标发送广播，或者处理来自所有引擎的RPC，客户端进程可以立即消耗存储节点上的所有内存，服务最终将被 OOM Killer 杀死。
+要求
+提高 DAOS 引擎可扩展性有几个要求：
+收集指标并了解每个 I/O RPC 的内存消耗
+定义正在处理的并发 RPC 的上限
+应预留一定的资源用于重建系统、聚合服务和其他应急服务
+当达到阈值时开始拒绝 RPC。
+客户端可以在一定时间间隔后重试被拒绝的 RPC
+重试间隔应该是随机的，否则如果所有客户端同时开始重试，它们将再次被拒绝
+被拒绝的 RPC 可能比常规 RPC 具有更高的优先级
+给 RPC 添加优先级？
+SWIM RPC始终具有最高优先级，最高优先级的RPC不应被拒绝
+常规 RPC 和高优先级 RPC 的单独阈值。
+重试时客户端堆栈可能会提高 RPC 优先级
+查看其他引擎组件的内存消耗
+ULT 堆栈大小
+您的缓存
+常规数据结构大小
+引擎端的通用内存消耗减少。
+设计概述
+DAOS 服务器 RPC 限制
+DAOS 服务器上的资源是有限的，如果服务线程不断为传入的 RPC 创建 ULT，其处理能力将在某个时刻跟不上接收速度，DAOS 引擎将被 OOM Killer 杀死。
+为了控制引擎端的资源消耗：
+DAOS 引擎应该跟踪传入 RPC 和创建的 ULT 的数量，这些计数器是每个 xstream 的。
+ULT 计数器：正在处理 RPC
+排队的 RPC 计数器：RPC 已排队（还没有 ULT）
+达到一定阈值后，引擎应停止处理传入的 RPC，并简单地拒绝它们。新的错误代码返回给客户端，也可以返回提示（可选）
+例如，提示基于过去 10 秒内正在处理、排队和拒绝的 RPC 数量
+提示可以是重试时间间隔：5-10秒、10-20秒、20-30秒。
+根据返回的错误代码，如果没有提示，DAOS 客户端将在随机时间间隔（在一定范围内）后重试 RPC，或者在服务器提示的时间间隔后重试。
+客户端决定重试间隔，或者服务器暗示重试间隔不应该以某种方式随机化，否则结构或服务器将过载，并且 RPC 可能会因拥塞而再次超时。
+helper xstream 上的 ULT 管理
+如今，每当 I/O xstream 将 RPC 转发卸载到 helper xstream 时，它总是在 helper xstream 上创建一个新的 ULT，这是昂贵的，因为每个 ULT 消耗数十千字节，并且 ULT 的上下文切换也会消耗 CPU 周期。
+因为 RPC 转发有一个非常简单的状态机，而不是为每个 RPC 批次创建数千甚至更多的 ULT：
+每个助手 xstream 创建一个 RPC 转发 ULT
+它还维护一个用于RPC转发任务的队列
+其他 xstream 可以在其中一个辅助 xstream 上对 RPC 转发任务进行排队
+RPC转发ULT可以处理排队的RPC转发任务
+大物体集体打拳
+详细信息可以在这里找到：DAOS-14105：集体冲压大型物体
+审查中
+
+SWIM 消息的低延迟流量类别
+根据与 HPE 的讨论，我们应该为 SWIM 使用“低延迟流量类别”，但这尚未由 Mercury 导出。
+SWIM RPC 决不应该被 DAOS 引擎限制。
+跟踪票：DAOS-14262：对 SWIM 使用低延迟流量类别
+进行中
+
+新的重发检查机制
+目前，DAOS 服务器依赖 DTX 表来检测重新发送的 RPC。但是从客户端到服务器没有用于 RPC 回复 ACK 的机制，因此 DAOS 服务器必须保存相关的已提交 DTX 条目，直到通过 DTX 聚合将其删除。主要有两个问题：
+DTX表会占用大量资源，尤其是DRAM。如果DTX聚合不能及时清除它们，可能会导致服务器OOM。
+DTX 聚合处理大量提交的 DTX 条目将影响常规 IO 进度，因为性能会定期波动。
+为了减少DTX表中已提交的DTX条目的数量，关键点是减少维护已提交的DTX条目的时间。基本思想是引入从客户端到服务器的间接 RPC 回复 ACK，该 ACK 通过后续 RPC 捎带至同一目标。一些关键想法：
+当线程向目标发送 RPC（任何类型）时，它将检查先前的修改 RPC 是否已回复，如果是，则通过当前 RPC 捎带其信息到目标。然后服务器可以知道相关的DTX条目可以从提交的DTX表中删除。
+在服务器端，如果某个 RPC 包含以前的 RPC 回复 ACK 信息，则将相关的 DTX 条目设置为可删除，然后后续的 DTX 聚合稍后会将它们从提交的 DTX 表中删除。另一方面，如果服务器无法及时获得某些DTX的回复ACK，则当早于某个基于时间的阈值时，相关的DTX条目将最终被DTX聚合删除。
+为了支持同时向同一目标发送多个 IO 请求，客户端将为每个线程维护一些积分数组。线程在向相关目标发送（修改）RPC之前，需要获得信用并保持该信用直到RPC被回复或失败。
+ 另一个重要因素是 DTX 聚合。目前，DTX聚合是VOS目标本地独立行为。这无法满足上述基于 RPC-reply-ACK 的 RPC 重发检测的要求。关键原因是DTX不是本地事务，而是可能跨越多个目标（对于复制对象或EC对象，或者对于分布式事务）。这意味着具有相同ID的DTX条目可能存在于多个目标上，但是具有前一个ACK的相关RPC仅发送到一个目标。那么当前收到ACK的目标需要让其他相关目标知道这个ACK。请注意，当前的 DTX 可能会与另一个冗余组一起工作，该冗余组与 RPC 中搭载的 ACK 不同，因此我们不能通过当前 DTX 的常规 IO 转发直接搭载它。在这种情况下，将DTX聚合改为全局操作更合适。这会导致服务器之间出现更多的RPC。但我们会将其作为批量操作，因此全局 DTX 聚合的相对开销可能不会太严重。
+此功能可能包括 RPC 格式更改，因此也应考虑互操作性。
+跟踪票：DAOS-14231：根据 RPC 回复 ACK 重新实现重新发送 RPC 的逻辑
+打开
+
+相关页面
+渐进式重返社会
+渐进式重返社会
+DAOS 社区
+经常一起读书
+蠕虫功能
+蠕虫功能
+DAOS 社区
+页面树图标
+一起组织
+新的日志记录和错误宏。
+新的日志记录和错误宏。
+DAOS 社区
+经常一起读书
+成为第一个添加反应的人
+
+
+
+---------------------------------------- DL ----------------------------------------
+---------------------------------------- DL ----------------------------------------
+---------------------------------------- DL ----------------------------------------

delete_space_line.py

@@ -0,0 +1,23 @@
+#!/usr/bin/python3
+import re
+import shutil
+
+print("删除多余的空行\n\n\n\n")
+f_output=open('output', 'w', encoding='utf8')
+with open('input', 'r', encoding='utf8') as f:
+  for line in f:
+    # print("line: ", ord(line.strip().replace(" ", "")))
+    # print(len(line))
+    find_result = re.findall('^[0-9]+$', line.replace("\n", ""))
+    if len(find_result) > 0:
+      continue
+    find_result = re.findall('^[0-9]+\.$', line.replace("\n", ""))
+    if len(find_result) > 0:
+      continue
+    mylist=[c for c in line if ord(c)!=10]
+    if mylist:
+      print("".join(mylist))
+      f_output.write("".join(mylist)+'\n')
+f_output.close()
+
+shutil.move("output", "input")

input

@@ -0,0 +1,77 @@
+引擎可扩展性加强, https://daosio.atlassian.net/wiki/spaces/DC/pages/11442552865/DAOS+engine+scalability+improvements
+DAOS 存储集群应该能够扩展到数千个存储服务器并处理来自数百万个客户端进程的 I/O 请求。DAOS使用的所有分布式协议都可以支持这种级别的可扩展性，但是，从软件设计和实现的角度来看，如果引擎侧没有资源控制，不断地向所有引擎的所有目标发送广播，或者处理来自所有引擎的RPC，客户端进程可以立即消耗存储节点上的所有内存，服务最终将被 OOM Killer 杀死。
+要求
+提高 DAOS 引擎可扩展性有几个要求：
+收集指标并了解每个 I/O RPC 的内存消耗
+定义正在处理的并发 RPC 的上限
+应预留一定的资源用于重建系统、聚合服务和其他应急服务
+当达到阈值时开始拒绝 RPC。
+客户端可以在一定时间间隔后重试被拒绝的 RPC
+重试间隔应该是随机的，否则如果所有客户端同时开始重试，它们将再次被拒绝
+被拒绝的 RPC 可能比常规 RPC 具有更高的优先级
+给 RPC 添加优先级？
+SWIM RPC始终具有最高优先级，最高优先级的RPC不应被拒绝
+常规 RPC 和高优先级 RPC 的单独阈值。
+重试时客户端堆栈可能会提高 RPC 优先级
+查看其他引擎组件的内存消耗
+ULT 堆栈大小
+您的缓存
+常规数据结构大小
+引擎端的通用内存消耗减少。
+设计概述
+DAOS 服务器 RPC 限制
+DAOS 服务器上的资源是有限的，如果服务线程不断为传入的 RPC 创建 ULT，其处理能力将在某个时刻跟不上接收速度，DAOS 引擎将被 OOM Killer 杀死。
+为了控制引擎端的资源消耗：
+DAOS 引擎应该跟踪传入 RPC 和创建的 ULT 的数量，这些计数器是每个 xstream 的。
+ULT 计数器：正在处理 RPC
+排队的 RPC 计数器：RPC 已排队（还没有 ULT）
+达到一定阈值后，引擎应停止处理传入的 RPC，并简单地拒绝它们。新的错误代码返回给客户端，也可以返回提示（可选）
+例如，提示基于过去 10 秒内正在处理、排队和拒绝的 RPC 数量
+提示可以是重试时间间隔：5-10秒、10-20秒、20-30秒。
+根据返回的错误代码，如果没有提示，DAOS 客户端将在随机时间间隔（在一定范围内）后重试 RPC，或者在服务器提示的时间间隔后重试。
+客户端决定重试间隔，或者服务器暗示重试间隔不应该以某种方式随机化，否则结构或服务器将过载，并且 RPC 可能会因拥塞而再次超时。
+helper xstream 上的 ULT 管理
+如今，每当 I/O xstream 将 RPC 转发卸载到 helper xstream 时，它总是在 helper xstream 上创建一个新的 ULT，这是昂贵的，因为每个 ULT 消耗数十千字节，并且 ULT 的上下文切换也会消耗 CPU 周期。
+因为 RPC 转发有一个非常简单的状态机，而不是为每个 RPC 批次创建数千甚至更多的 ULT：
+每个助手 xstream 创建一个 RPC 转发 ULT
+它还维护一个用于RPC转发任务的队列
+其他 xstream 可以在其中一个辅助 xstream 上对 RPC 转发任务进行排队
+RPC转发ULT可以处理排队的RPC转发任务
+大物体集体打拳
+详细信息可以在这里找到：DAOS-14105：集体冲压大型物体
+审查中
+
+SWIM 消息的低延迟流量类别
+根据与 HPE 的讨论，我们应该为 SWIM 使用“低延迟流量类别”，但这尚未由 Mercury 导出。
+SWIM RPC 决不应该被 DAOS 引擎限制。
+跟踪票：DAOS-14262：对 SWIM 使用低延迟流量类别
+进行中
+
+新的重发检查机制
+目前，DAOS 服务器依赖 DTX 表来检测重新发送的 RPC。但是从客户端到服务器没有用于 RPC 回复 ACK 的机制，因此 DAOS 服务器必须保存相关的已提交 DTX 条目，直到通过 DTX 聚合将其删除。主要有两个问题：
+DTX表会占用大量资源，尤其是DRAM。如果DTX聚合不能及时清除它们，可能会导致服务器OOM。
+DTX 聚合处理大量提交的 DTX 条目将影响常规 IO 进度，因为性能会定期波动。
+为了减少DTX表中已提交的DTX条目的数量，关键点是减少维护已提交的DTX条目的时间。基本思想是引入从客户端到服务器的间接 RPC 回复 ACK，该 ACK 通过后续 RPC 捎带至同一目标。一些关键想法：
+当线程向目标发送 RPC（任何类型）时，它将检查先前的修改 RPC 是否已回复，如果是，则通过当前 RPC 捎带其信息到目标。然后服务器可以知道相关的DTX条目可以从提交的DTX表中删除。
+在服务器端，如果某个 RPC 包含以前的 RPC 回复 ACK 信息，则将相关的 DTX 条目设置为可删除，然后后续的 DTX 聚合稍后会将它们从提交的 DTX 表中删除。另一方面，如果服务器无法及时获得某些DTX的回复ACK，则当早于某个基于时间的阈值时，相关的DTX条目将最终被DTX聚合删除。
+为了支持同时向同一目标发送多个 IO 请求，客户端将为每个线程维护一些积分数组。线程在向相关目标发送（修改）RPC之前，需要获得信用并保持该信用直到RPC被回复或失败。
+ 另一个重要因素是 DTX 聚合。目前，DTX聚合是VOS目标本地独立行为。这无法满足上述基于 RPC-reply-ACK 的 RPC 重发检测的要求。关键原因是DTX不是本地事务，而是可能跨越多个目标（对于复制对象或EC对象，或者对于分布式事务）。这意味着具有相同ID的DTX条目可能存在于多个目标上，但是具有前一个ACK的相关RPC仅发送到一个目标。那么当前收到ACK的目标需要让其他相关目标知道这个ACK。请注意，当前的 DTX 可能会与另一个冗余组一起工作，该冗余组与 RPC 中搭载的 ACK 不同，因此我们不能通过当前 DTX 的常规 IO 转发直接搭载它。在这种情况下，将DTX聚合改为全局操作更合适。这会导致服务器之间出现更多的RPC。但我们会将其作为批量操作，因此全局 DTX 聚合的相对开销可能不会太严重。
+此功能可能包括 RPC 格式更改，因此也应考虑互操作性。
+跟踪票：DAOS-14231：根据 RPC 回复 ACK 重新实现重新发送 RPC 的逻辑
+打开
+
+相关页面
+渐进式重返社会
+渐进式重返社会
+DAOS 社区
+经常一起读书
+蠕虫功能
+蠕虫功能
+DAOS 社区
+页面树图标
+一起组织
+新的日志记录和错误宏。
+新的日志记录和错误宏。
+DAOS 社区
+经常一起读书
+成为第一个添加反应的人

readme

@@ -3,6 +3,8 @@ daos开发文档: https://docs.daos.io/v2.5/dev/development/
 daos开发文档_容器增删改查: https://docs.daos.io/v2.5/user/container/, 用户文档: https://docs.daos.io/v2.5/user/workflow/
 公共组件: https://github.com/daos-stack/daos/tree/master/src/common
 c_raft实现: https://github.com/willemt/raft, 文档: raft.h, 
+vos(翻译): https://blog.csdn.net/Hahafly1234/article/details/119298746
+
 
 依赖缓存包: http://rz2fg6ogr.hn-bkt.clouddn.com/cache_tgz