diff --git "a/web-ui/docs/zh/blog/fengchunsong/DAOS ARM64\350\260\203\346\265\213\344\271\213\346\227\205.md" "b/web-ui/docs/zh/blog/fengchunsong/DAOS ARM64\350\260\203\346\265\213\344\271\213\346\227\205.md"
new file mode 100644
index 0000000000000000000000000000000000000000..f4730b53afbadae4ad6bd266ca4c3052fa4c2958
--- /dev/null
+++ "b/web-ui/docs/zh/blog/fengchunsong/DAOS ARM64\350\260\203\346\265\213\344\271\213\346\227\205.md"	
@@ -0,0 +1,46 @@
+# DAOS ARM64调测之旅
+
+## 背景概述
+
+ 从IO500榜单上了解到，前10名有一半是DAOS，这是什么样一款存储软件，能如此优秀？从HDD到SSD，仅仅是性能提升、延迟降低，从SSD到SCM，不仅仅是性能提升，还支持按字节事务性访问，异常后回滚。SCM不带DMA，访问过程消耗大量的CPU资源，从软件架构上优化，就是想办法减少拷贝过程，诞生了RDMA零拷贝；从硬件上优化，intel推出了DSA加速器。DAOS+SCM新架构值得在ARM64上尝试。
+
+## 编译问题
+
+ DAOS官网上明确说仅支持x86+Optane内存+NVMe SSD商用化，同时提供了用内存模拟Optane内存的实验特性。ARM64跑DAOS就有了可能。我们首先进行了版本编译，碰到了静态检查结构体大小报错。通过分析发现根因是pthread_mutex在不同平台上，长度是不一样的，x86 64是40字节，ARM64是48字节，多了8字节，触发了结构体大小断言报错。提问题单，社区帮忙调整数据结构解决了断言错误。接下来就是依赖的SPDK组件编译报错，DAOS设置spdk_arch是x86，修改为读编译主机arch，是ARM64就使用native方式编译，解决了SPDK编译报错问题。再下来是缺少libipmctl.so，ipmctl是intel Optane的管理工具，只有x86版本，ARM64需要去掉libipmctl依赖，增加ipmctl空接口后，解决了依赖报错问题。telemetry的go代码限制只有amd64编译，修改为amd64、arm64都编译。最后一个问题是Dup2在ARM64上不支持，使用Dup3来支持Dup2。
+
+## IO500调测
+
+ 版本编译出来后，在ARM64上部署测试，一跑就挂死，调用栈是问号，打开所有调试信息，每次挂死前都是在mercury网络模块，无法进一步定位。直觉判定可能是内核页大小问题导致的，x86只支持4K页，ARM64支持4K、16K、64K页，改成4K页后，就能正常跑起来不挂死了。又出现了新问题，找不到网络接口，异常退出了。看日志，不支持bond、vlan等虚拟网络设备，改成使用物理网卡后，网络正常识别，集群正常起来。不一会就出现网络超时故障，查看日志有的是4秒超时，有的是请求发出去立即就超时了，看起来是集群间时间没有同步，对端收到后时间差超过超时门限，触发超时流程，时间同步后，几秒超时问题消失。跑一段时间后还是出现超时，且系统明显卡顿，查看CPU并不忙，查看内存free情况，发现内存很少，perf抓火焰图，发现内存申请走了慢路径申请，减少模拟Optane的内存大小后，网络超时问题消失。IO500测试60~70秒左右，就出现集群空间满，测试终止。查看SCM空间已用完，NVMe空间剩余还很大。上社区论坛查到，元数据只保留在SCM上，SCM空间不足也不会转存到NVMe中，直接上报空间不足错误。只能加大物理内存，从256GB加到512GB后，保留了更多的内存，IO500能测试到200秒左右还是耗光了SCM，IO500需要测试300秒，成绩才是有效的，因此需要想办法减少SCM空间使用。从DAOS架构图上看到SCM内存用来存放元数据、非对齐的数据、小块数据，查看代码，小块数据默认是4K以下就存SCM。修改容器属性，io门限值降低到2K，这样IO500终于能测试完。增加target个数，增加并发度，又出现了SCM耗尽，仔细读DAOS文档，提到每个target会预留SCM、NVMe内存做聚合使用，查看代码找到了SCM会保留2GB、NVMe保留10GB，没有设置接口，直接修改代码SCM保留512MB，每个target节省了1.5GB，一个rank 16个target共节省了24GB内存，每个rank总共分配了90GB，节省了26%的内存。IO500跑完再没出现过SCM耗尽，性能也得到了大幅提升。逐步增加客户端个数，发现mdtest部分测试项随着并发度增加能一直增加，说明客户端有瓶颈，10台客户端里有4台性能较差，更换性能更好的客户端后，性能进一步提升。开启端到端校验后测试，发现sha512新建容器大概率失败，X86每次都是成功的。执行isal_crypto下的sha512测试用例，都是通过的。看github问题列表，发现2021年就有人上报了在ARM64上sha512值错误并提供了测试程序。分析sha512代码，发现缺少了多次更新不足一块数据的追加处理，修复后，测试程序通过，DAOS端到端sha512校验也通过了。
+
+## 功能验证
+
+ 由于IO500只跑性能，没有校验数据是否正确，我们通过复制大量不同大小的文件到DAOS文件系统，重启DAOS集群后，再复制回来，检查前后的md5值是否一致，来校验数据是否正确。前后md5值是一致的，确认数据一致性没有问题。压力测试大概率出现复制回来过程中，服务端coredump，看log是池版本号为NULL触发断言，待分析。扩展测试了2/3副本、EC 2+1 2+2 4+2，数据校验均正确。
+
+ 在社区上看到DAOS计划用容器来支持块设备，目前容器不支持预先指定容量。DAOS提供dfs插件支持fio测试，实际还是文件系统，并不是块设备。fio测试了单IO时延，写4K随机写110us、读160us、混合读写150us，接近100us。单台服务器4K多并发随机写测试420K IOPS。fusionstorage、阿里云已经能做到50us，100万IOPS，看来还有优化空间。
+
+ ARM64运行DAOS还有哪些问题？我们执行了daos_test、run_test.sh，跟x86对比测试，发现ARM64上出现vos小io测试错误、epoch错误、对象检查错误，分析测试代码，发现是测试代码本身的问题，x86能通过是因为局部变量初始值是0，ARM64初始值是随机的，修改测试代码后，这三个用例能通过。还发现EC一个用例失败，正在分析中，其他测试都跟x86一致。
+
+## 总结展望
+
+ DAOS ARM64调测过程总体来说，比较顺利，主要是断言比较多，能快速定位问题。大量使用spdk、isal、isal_ctypto,pmdk模块，ARM64已经很好的适配过这些模块，因此很少补丁改动，即可在arm64上编译通过，运行稳定。dashboard使用promethues+grafana，性能测试过程可视化，方便诊断性能。每个target单线程，没有多线程并发冲突问题，也就没有ARM64弱序问题。问题分析过程中，大量参考了DAOS社区问题单，分析步骤详细，提供了分析思路。
+
+ 后续重点在社区添加ARM64 CI，覆盖多种OS编译、单元测试，定期取主线版本进行性能测试。使用内存备电验证pmdk刷cache、数据校验正确性验证。社区版本支持UCX、NVMe of RDMA模块后，进行ARM64UCX、NoF功能测试。
+
+## ARM64补丁列表
+
+[DAOS-10569 client: fix build on aarch64](https://github.com/daos-stack/daos/pull/8998)
+
+[DAOS-10148 tse: fix TSE task buffer to account for aarch64](https://github.com/daos-stack/daos/pull/8984)
+
+[DAOS-10871 build: Fix aarch64 build SPDK error](https://github.com/daos-stack/daos/pull/9398)
+
+[DAOS-10872 control: Fix aarch64 build control errors ](https://github.com/daos-stack/daos/pull/9401)
+
+[DAOS-10922 control: Implement ipmctl for aarch64](https://github.com/daos-stack/daos/pull/9505)
+
+[DAOS-10899 test: use expected variable to do assert checking](https://github.com/daos-stack/daos/pull/9487 )
+
+[DAOS-10898 obj: fix the assert in small_io test](https://github.com/daos-stack/daos/pull/9486)
+
+[DAOS-10891 tests: fix incorrect assert in check_oclass](https://github.com/daos-stack/daos/pull/9456 )
+
diff --git "a/web-ui/docs/zh/blog/rosinL/2022-8-16-Ceph\347\244\276\345\214\272\345\212\250\346\200\201(2022-7-1~2022-7-31).md" "b/web-ui/docs/zh/blog/rosinL/2022-8-16-Ceph\347\244\276\345\214\272\345\212\250\346\200\201(2022-7-1~2022-7-31).md"
new file mode 100644
index 0000000000000000000000000000000000000000..9bcb37b1e0b025c5d1933a132baf9ceea7d58ae4
--- /dev/null
+++ "b/web-ui/docs/zh/blog/rosinL/2022-8-16-Ceph\347\244\276\345\214\272\345\212\250\346\200\201(2022-7-1~2022-7-31).md"
@@ -0,0 +1,92 @@
+---
+title:Ceph社区动态	（2022-7-1~2022-7-30）
+date:2022-8-13
+tags:
+-Ceph
+-动态
+-Pacific
+-OpenEuler
+sig:sig-SDS
+archives:2022-08
+author:fengchunsong
+summary:Ceph社区动态
+---
+# Ceph社区动态	（2022-7-1~2022-7-30）
+
+## Quincy超大规模部署测试
+使用200台服务器+100Gb网络部署quincy测试，主要评估集群管理、监控模块。发现了两个主要问题：Ceph守护进程上报性能计数导致mgr、CLI响应卡顿、横向扩展[`pg_autoscaler`](https://docs.ceph.com/en/quincy/rados/operations/placement-groups/#autoscaling-placement-groups)会影响pg间peering,都已经修复。使用cephadm管理大集群时，出错时错误信息过多、代理日志流量过大、集群管理交互困难，进行了优化。Prometheus管理大集群时无法一次收集所有监控节点，需要选择更好的SSD来存储数据。
+
+## Ceph安全漏洞修复
+修复如下两个安全漏洞，发布[v16.2.10](https://ceph.io/en/news/blog/2022/v16-2-10-pacific-released/)和[v17.2.2](https://ceph.io/en/news/blog/2022/v17-2-2-quincy-released/)版本，建议升级：
+
+- 将其Ceph集群从Nautilus(或更早版本)升级到更高的主线版本，则很容易受到恶意用户的攻击。该漏洞允许用户访问CephFS文件系统层次结构的任意部分，而不是被正确限制在自己的子卷上。漏洞已修复。
+
+- s3website请求不引用桶，从而出现空指针，导致RGW segfault,已修复。
+
+## Ceph RocksDB深度调优
+介绍了Ceph的默认RocksDB优化，并将其与其他几种配置进行了比较。我们研究了这些设置如何影响NVMe驱动器上的写入放大和性能，并试图展示不同配置选项之间的交互有多复杂。似乎通过正确的选项组合，可以在不显著增加写入放大的情况下实现更高的性能。在某种情况下，启用压缩可能会降低写入放大，并在某些测试中对性能产生中等影响。在这些测试中，通常性能最高的配置似乎是：
+无压缩：
+
+```
+bluestore_rocksdb_options = compression=kNoCompression,max_write_buffer_number=128,min_write_buffer_number_to_merge=16,compaction_style=kCompactionStyleLevel,write_buffer_size=8388608,max_background_jobs=4,level0_file_num_compaction_trigger=8,max_bytes_for_level_base=1073741824,max_bytes_for_level_multiplier=8,compaction_readahead_size=2MB,max_total_wal_size=1073741824,writable_file_max_buffer_size=0
+```
+LZ4压缩（RGW负载可以减少写放大，但对桶列表性能有影响）:
+```
+bluestore_rocksdb_options = compression=kLZ4Compression,max_write_buffer_number=128,min_write_buffer_number_to_merge=16,compaction_style=kCompactionStyleLevel,write_buffer_size=8388608,max_background_jobs=4,level0_file_num_compaction_trigger=8,max_bytes_for_level_base=1073741824,max_bytes_for_level_multiplier=8,compaction_readahead_size=2MB,max_total_wal_size=1073741824,writable_file_max_buffer_size=0
+```
+这些非默认配置提升了性能，但还没有经过大量测试。在接下来的几个月里，我们将通过QA运行这些配置，并可能考虑更改Ceph下一个版本的默认值。
+
+## 近期社区合入pr
+近期pr主要以bug修复为主，摘选了主要特性修改如下所示：
+* MemDB:
+  - 为了简化buffer库，删除了MemDB代码，不再支持MemDB[#36282](https://github.com/ceph/ceph/pull/36282)
+  - 删除每个txc上的statfs更新，这降低了DB负载可以提升更好的性能[#46036](https://github.com/ceph/ceph/pull/46036)
+- compressor/zlib:
+  
+  - arm64 zlib使用isa-l优化性能提升4~7倍[#44762](https://github.com/ceph/ceph/pull/44762)
+- libcephsqlite
+  
+  - 正规则表达式'-'在gcc8.5.0-14上编译会导致libcephsqlite崩溃，转义符修复[#47270](https://github.com/ceph/ceph/pull/47270)
+- crimson
+  
+  - 解决停掉OSD时泄露ClientRequests[#47064](https://github.com/ceph/ceph/pull/47064)
+  - 修复因重用移动对象而导致的sigsegv[#47237](https://github.com/ceph/ceph/pull/47237)
+  - 修复Transaction::is_retired指针强制转换导致未定义行为[#47081](https://github.com/ceph/ceph/pull/47081)
+- rgw
+  
+  - 优化抢锁，将5秒等待细分为多个10ms重试，减少持锁等待时间[#46248](https://github.com/ceph/ceph/pull/46248)
+  - 增加s3website检查条件解决“未指定桶名时程序崩溃”问题[#46933](https://github.com/ceph/ceph/pull/46933)
+- mgr大集群管理优化
+  
+  - 避免进度更新时dump所有pg统计信息[44208](https://github.com/ceph/ceph/pull/44208)
+  
+  - 限制对pg_num在pgp_num内更改[#44155](https://github.com/ceph/ceph/pull/44155)
+  
+  - 仅在模块需要通知时传递通知mgr[#44162](https://github.com/ceph/ceph/pull/44162)
+
+## 近期Ceph Developer动态
+Ceph社区各个模块会定期举行会议，讨论和对齐开发进展，会后有视频上传至[youtube](https://www.youtube.com/channel/UCno-Fry25FJ7B4RycCxOtfw/videos)，主要会议信息如下：
+|会议名称|说明|频率|
+|-------|----|----|
+|Crimson SeaStore OSD Weekly Meeting |Crimson & Seastore开发周例会|周|
+|Ceph Orchestration Meeting|Ceph管理模块（Mgr）开发|周|
+|Ceph DocUBetter Meeting |文档优化|双周|
+|Ceph Performance Meeting|Ceph性能优化|双周|
+|Ceph Developer Monthly|Ceph开发者月度例会|月|
+|Ceph Testing Meeting|版本验证及发布例会|月|
+|Ceph Science User Group Meeting|Ceph科学计算领域会议|不定期|
+|Ceph Leadership Team Meeting|Ceph领导团队例会|周|
+|Ceph Tech talks|Ceph社区技术相关主题讨论|月|
+
+### Performance Meeting
+- v17.2.1比v17.2.0性能降低
+  - 对比版本更改，找到bluestore的零块检测功能，在v17.2.0默认开启，在v17.2.1默认关闭。
+- Ceph RocksDB深度调优
+  - 主要讨论了rgw压缩，开启压缩写、删除性能较好，且写入流量更低。读性能使用lz4性能不会降低。如果限制rgw守护进程只使用2个核，查询桶列表时性能会降低，读、写、删除性能不变
+  - 讨论RocksDB删除数据的墓碑清理、压缩策略，设置一个迭代窗口，在窗口内，超过阈值就压缩墓碑。
+  - 讨论bluestore statfs统计信息优化，为即将实施的新WAL的做准备
+
+### Crimson SeaStore OSD Weekly Meeting
+- 修复zns支持相关问题
+- GC事务不是由用户行为来源的，因此来自GC事务的范围读取操作不满足时间局部性原则。这些扩展区不应添加到LRU缓存中。
+