标签：cow bluestore chunk write io small 对齐 clone size
文章目录
第一部分：原理介绍
环境介绍：
EC模式 2+1
dd if=/dev/zero of=file bs=6k count=10 oflag=direct
6k IO拆分成3k到每个osd上，补齐到bdev_size(4k)后执行write
1、第一次写
new Blob(Blob1)， 从磁盘中alloc blob(blob1 大小为min_alloc_size 64k)
3k的io补零后和bdev_size对齐，写到blob1的extent1
第二次写（覆盖extent1的补零部分）
两种方式选择，可由配置参数bluestore_clone_cow选择
默认bluestore_clone_cow = true 使用cow模式覆盖
cow模式下将第二个io分为两次写执行：
clone 原始的lextent1; ->
使用前1k io补齐lextent1, 写到lextent2; ->
后2k io 补零后写到lextent3; ->
释放lextent1对pextent1的引用 ->
remove 克隆后的临时onode, 释放临时lextent对pextent1的引用，进而释放blob1
(1)_do_clone_range
clone之后磁盘上的extent1被Blob1和Blob2中的两个lextent共享，blob1成为shared_blob(blob->ref = 2)
（2）do_write_small写拼好的第一个4k
do_write_small—new_blob
_do_alloc_write txc 0x7f5026c33080 1 blobs
(3)do_write_small写剩余的2k数据（pad_zero补齐到bdev_size）
（4）回收垃圾
estimate gc range(hex): [0, 1000)
释放Blob1中的lextent1对blob1的引用
回收垃圾之后的映射效果：
blob1的引用计数减1，Blob1中第一个4k数据映射到extent2上
（5）remove 临时onode,回收blob1的磁盘空间
删除临时onode，释放blob1
1.第三个io
同理，第三个io下来时，分为两次写操作：
cow方式覆盖写extent2;
补零后写extent3
执行完各个op的io映射图如下：
分析：
由于第三个io下来只覆盖写lextent2，所以只有这部分执行cow,数据写在新的blob（blob3）上, 老的blob（blob2）上还有已经写好的extent1，所以不能释放
同理申请blob4执行第四次写io
执行后的io映射图如下：
当执行下一次io时：
由于不需要覆盖写，所以不需要再申请新的blob，复用blob4
综上，当ec小写拆分出的io与bdev_size非对齐时，执行cow覆盖写会对磁盘空间造成浪费；
如：2+1模式，6k io顺序写
磁盘浪费3/4（每4次写需要新申请3个blob）
2+1模式， 4k io顺序写时
磁盘浪费1/2（每两次写需要新申请1个新的blob）
第二部分：测试数据支持及场景应用
（1） 磁盘浪费测试（cow浪费磁盘空间， rmw不浪费磁盘空间）
Cow模式下拆分到每个osd上的io，看是否和bdev_size（4k）对齐:
如果大小为1k, 则每4次写申请一个blob
如果大小为2k, 则每4次写申请2个blob
如果大小为3k, 则每4次写申请3个blob
如果大小和bdev_size对齐，则不会有磁盘空间浪费
（2）cow模式下浪费的空间再使用rmw模式覆盖写，磁盘空间回收测试
（3）cow模式覆盖写后，再使用cow模式覆盖写测试
第三部分：rmw模式下没有磁盘浪费说明：
直接读取，合并，写入；不申请额外的空间
第四部分 bluestore默认使用cow模式而不用rmw的原因
环境介绍：
cephfs的数据资源池使用2+1的ec pool,组成为osd.0 osd.2 osd.3
为了避免写元数据时对small write统计的影响，元数据资源池使用其他osd创建，和数据osd隔离
（一）以osd.0为例，执行顺序小写时使用cow模式进行clone
（1）在执行写操作之前：
bluestore_write_small = 3183
（2）执行bs=6k count=36的写操作：
（3）执行后，osd.0 的数据统计如下：
bluestore_write_small = 3237
dd数据之后， bluestore执行small_write的次数为3237 – 3183 = 54次
下面分析osd.0在cow模式下接收36次大小为3k（拆分后）的io下发时实际进行54次小写的原因：
接收36次3k io 需要clone的次数 = 36 * 3 / 4 = 27 （原理见第一部分）
每次执行clone需要执行small write的次数 = 2 (一次合并后的数据， 一次补零后的新数据)
所以一共执行small write的次数为27 * 2 = 54 次
（二）将osd.0 clone的模式修改为rmw
测试同样下发36次，大小为3k的io，实际执行small write的次数
（1）下发io之前的数据统计：
bluestore_write_small = 3237
1、执行io下发操作
拆分后，落在osd.0 上的io大小为36次3k写
1、执行完写之后， osd.0的数据统计
bluestore_write_small = 3318
dd数据之后， bluestore执行small_write的次数为3318 – 3237 = 81次
下面分析osd.0在rmw模式下接收36次大小为3k（拆分后）的io下发时实际进行81次小写的原因：
接收36次3k io 需要clone的次数 = 36 * 3 / 4 = 27 （原理见第一部分）
每次clone操作需要执行的small write的次数 = 3（除cow模式下的那两次，还有clone时的一次）
所以， 总共执行的small write次数为 27 * 3 = 81次
综上，当执行小写时，bluestore在执行small write时会有放大，根据覆盖写时执行clone的模式的不同，放大的情况也不一样：
当clone模式为cow时：每次clone对于small_write的放大为1倍
当clone模式为rmw时: 每次clone对于small_write的放大为2倍
cow :
bluestore_write_small = num * size / bdev_size * 2
rmw:
bluestore_write_small = num * size / bdev_size * 3
其中：
num 下发的写io个数
size： ec拆分完落在每个osd上的io大小，单位是k
bdev_size: 默认大小4k
num * size / bdev_size即为num个非对齐小io下发时，执行clone的次数（也是执行read的次数）
第五部分 总结
rmw模式下虽然不会造成磁盘空间的浪费，还能够在覆盖写时回收已经浪费的磁盘空间，但是在执行覆盖小写的过程中产生比cow模式更多的写放大，而越多的deffer写就会带来更多的读操作，bluestore的小写性能也会产生更大的瓶颈；cow模式下根据实际拆分后的io大小带来不同程度上的磁盘浪费（拆分后的size余越接近bdev_size浪费的越多——见第一部分和第二部分），但是对于small write，写放大相对较小，对性能的影响更小，实际环境部署时，可根据业务需要灵活配置。
学无止境966
发布了50 篇原创文章 · 获赞 6 · 访问量 6748
私信
关注
标签：cow,bluestore,chunk,write,io,small,对齐,clone,size 来源： https://blog.csdn.net/qq_23929673/article/details/104033338
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。