diff --git a/chenhongyu/pic/Image5.png b/chenhongyu/pic/Image5.png
index 9fb8dfe623e10b74f3af581bebb0f924b842c057..bc72ba689e4889ab61ee06f0b6a6f35a34290781 100644
Binary files a/chenhongyu/pic/Image5.png and b/chenhongyu/pic/Image5.png differ
diff --git a/chenhongyu/pic/Image6.png b/chenhongyu/pic/Image6.png
new file mode 100644
index 0000000000000000000000000000000000000000..725bb810556dc27988f5cbe7951006b93cd28946
Binary files /dev/null and b/chenhongyu/pic/Image6.png differ
diff --git a/chenhongyu/zstorage_striping.md b/chenhongyu/zstorage_striping.md
index e2bcfd9bab14286ee713af358a3e6a1b32ed9bce..21da2b5650e55e2aeec946319cdf9f6174a0aebb 100644
--- a/chenhongyu/zstorage_striping.md
+++ b/chenhongyu/zstorage_striping.md
@@ -5,14 +5,14 @@
 ## 二、zStorage分布式存储技术概述
 ##### 1、关键名词说明
 * **OSD（Object Storage Device）**：一个抽象的硬盘。可以是一个HDD或者SSD，也可以是一个RAID组中的一个LUN，或者一个文件。
-* **Chunk**：zStorage将卷（Volume）切分为大小相同的多个Chunk，它们存储在不同的节点的不同OSD上，zStorage能够充分利用多节点处理并发能力对一个卷提供更高的访问性能。Chunk的大小在集群创建的时可配置，默认大小为4MB。
+* **Chunk**：zStorage将卷（Volume）切分为大小相同的多个Chunk，它们存储在不同的节点的不同OSD上，使得能够充分利用多节点的并发处理能力对一个卷提供更高的访问性能。Chunk的大小在集群创建的时可配置，默认大小为4MB。
 * **PG（Placement Group）**：zStorage默认冗余策略是一主二备的三副本模式，为了放置Chunk的副本，zStorage引入了PG的概念，三副本模式的PG由三个节点上的三个OSD组成。
 ##### 2、zStorage框架
 * 一个zStorage集群由多个服务器节点构成，一个服务器节点可以有多个OSD（Object Storage Device）。
-![alt text](pic/Image0.png)
+>![alt text](pic/Image0.png)
 ##### 3、zStorage的数据分散处理
 * 以三副本为例，一个卷（Volume）被拆分为一个个Chunk，根据Chunk的下标计算出所属的PG，PG的三个OSD位于三个不同的节点，其中有一个主OSD，zStorage所有节点负载的主OSD数量达到均衡，每一个Chunk的IO请求只能发到主OSD所属的节点。
-![alt text](<pic/Image1.png>)
+>![alt text](<pic/Image1.png>)
 ## 三、zStorage中的数据条带化实践
 ##### 1、问题背景
 * 在zStorage中，数据被切分为多个Chunk，并分散存储于不同的节点上。这种设计使得系统能够充分利用多节点的并发处理能力，提升整体性能。
@@ -27,32 +27,40 @@
 * ②1 <= stripe_width
 * ③chunk_length % stripe_length == 0
 * ④(chunk_length / stripe_length) % stripe_width == 0
-* 前三个约束条件比较好理解，按照配置的stripe_length，**数据必须能被整齐拆分**。
-* 第四个约束条件，stripe_width可以理解为节点个数，如果stripe_length过小，一个Chunk被拆分的份数大于节点个数，**被拆分的份数必须是节点个数的倍数**。
+    >前三个约束条件比较好理解，按照配置的stripe_length，**数据必须能被整齐拆分**。<br>
+    >第四个约束条件，stripe_width可以理解为节点个数，如果stripe_length过小，一个Chunk被拆分的份数大于节点个数，**被拆分的份数必须是节点个数的倍数**。
 ##### 4、示例图
 * 通过条带化，将一个Chunk平均切分成多个小的数据块（stripe_length），然后映射到多个相邻的chunk上（stripe_width）， 这样就可以把一个Chunk上的io负载均衡到多个节点上。
-![alt text](<pic/Image2.png>)
-![alt text](<pic/Image3.png>)
+>![alt text](<pic/Image2.png>)
+>![alt text](<pic/Image3.png>)
 ##### 5、未对齐的IO请求处理
 * 数据条带化是存储系统内部的一种优化手段，对于系统使用者而言，这一优化是无感知的。在实际操作中，IO请求的偏移量和条带化的偏移量往往并不一致，这就需要存储系统进行相应的调整和处理。
 * 以下图为例，**浅蓝色部分代表IO请求**，它跨越了四个stripe数据块。而经过数据条带化处理，**映射后的IO请求**被分别映射到了四个不同的Chunk上。在这个过程中，存储系统需要根据原始IO请求的偏移量和数据长度，精确地计算出映射后四个小IO请求的偏移量和数据长度。随后，这四个小IO请求会分别被发送到四个不同的节点进行处理，并最终将结果合并后返回给使用者。
-* 这一过程虽然复杂，但在zStorage的算法实现中，却能够高效且准确的处理，确保数据的完整性和性能的优化。
-![alt text](<pic/Image4.png>)
+* 这个过程比较复杂，zStorage有自己的算法实现，能够高效且准确的处理，确保数据的完整性和性能的优化。
+>![alt text](<pic/Image4.png>)
 ##### 6、可配置的条带化参数
 * 条带化技术的引入，正是为了针对性地解决单流IO所面临的挑战。对于连续IO密集型的应用，条带化无疑是一种理想的选择，它能有效分散IO负载，提升系统性能。然而，对于数据库这种随机IO较多或者IO并发度较高场景，条带化可能并非最优策略。
 * 硬件支持的条带化通常要求整个硬件平台上的所有卷（Volume）采用统一的条带化配置，这种限制使得系统灵活性受限，难以适应多样化的应用需求。
 * zStorage从软件层面实现的条带化，允许每个卷（Volume）拥有**独立的条带化配置**，这种设计使得系统能够更加灵活地应对不同应用场景的需求，无论是需要高效连续IO的应用，还是随机IO占主导的场景，zStorage都能通过精细化的条带化配置，为用户提供更好的性能体验。
-##### 7、测试效果
-* 使用fio工具进行测试，通过numjobs参数和iodepth参数控制单流还是并发，通过bs参数控制io大小。
+##### 7、zStorage和LVM条带化性能对比
+* 测试工具：fio，通过numjobs参数和iodepth参数控制单流还是并发，通过bs参数控制io大小。
 ```
-/usr/bin/fio --name=Read_Test --rw=read --bs=4m --group_reporting=1 --direct=1 --numjobs=7 --time_based=1 --runtime=15 --ioengine=libaio --iodepth=6 --filename=/dev/nvme0n4
+/usr/bin/fio --name=Read_Test --rw=read --bs=4m --group_reporting=1 --direct=1 --numjobs=7 --time_based=1 --runtime=60 --ioengine=libaio --iodepth=6 --filename=/dev/mapper/vgbz-storage
 ```
-![alt text](<pic/Image5.png>)
-* 测试结果说明：单流设置numjobs和iodepth为1，并发设置numjobs为7和iodepth为6。
-1、在单流情况下，对于4k的小IO，性能影响不大。对于4m的大IO，性能提升7-8倍。
-2、在并发情况下，性能反而下降3-4倍。原因在于并发情况下多个节点都有负载，进行条带化反而会增加额外的延迟和开销。
+* 测试参数设置：单流设置numjobs和iodepth为1，并发设置numjobs为7和iodepth为6。
+* 条带化参数：zStorage和LVM都设置128K的条带长度。
+* 测试结果：分别测试在单流和并发情况下，4k和4m大小的IO性能，测试时长为60s，分别测三次取平均值。
+>![alt text](<pic/Image5.png>)
+>![alt text](<pic/Image6.png>)
+* 测试结果分析：
+    1. 对于4k的小IO，不论是单流还是并发，是否有条带化，性能差异不大，反而条带化后性能有少许下降，原因就在于小IO享受不到条带化带来的优化，反而有可能增加增加额外的延迟和开销。
+    2. 对于4m的大IO，单流场景下，zStorage性能提升8倍左右，LVM性能提升3-4倍。
+    3. 对于4m的大IO，并发场景下，zStorage性能提升2-3倍，LVM性能提升1-2倍。
+* 总结：
+    1. 通过对zStorage和LVM两种方式条带化的性能测试，可以看到条带化对于大IO性能优化比较明显，尤其在单流场景下优化效果更加明显。
+    2. 如果使用zStorage存储系统，那么更推荐使用zStorage自带的条带化功能。从性能角度看，zStorage的条带化优化效果是LVM的两倍左右，从使用方法看，LVM需要创建多个卷组成vg才能实现条带化，但zStorage封装的条带化可以针对每一个卷，对使用者比较方便。
 ## 四、数据条带化的性能优势与挑战
-* 数据条带化通过将单流IO分散到多个节点处理，zStorage避免了某个节点的过载情况，从而提高了整体性能。同时，可配置的特性还使得系统能够更灵活地应对不同的应用场景和IO模式。
+* 数据条带化通过将单流IO分散到多个节点处理，可以避免某个节点的过载情况，从而提高了整体性能。同时，支持可配置的特性还使得系统能够更灵活地应对不同的应用场景和IO模式。
 * 与此同时，数据条带化也带来了一些挑战，条带化过程将数据拆分为更小的数据块，这在一定程度上导致了IO操作的碎片化，一个原本简单的IO请求现在需要被拆分为多个子请求，分别在不同的节点上执行，最后再将结果合并返回。这一过程不仅增加了系统的复杂性，还可能引入额外的延迟和开销。
 * 因此，在使用数据条带化技术时，我们需要综合考虑使用场景、硬件性能等多种因素，**合理配置条带化参数**。只有在充分考虑这些因素的基础上，才能确保数据条带化技术能够真正发挥其性能优势。
 ## 五、未来展望