bluestore处理非chunk对齐小写时的模式说明
作者:互联网
文章目录
第一部分:原理介绍
环境介绍:
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,写放大相对较小,对性能的影响更小,实际环境部署时,可根据业务需要灵活配置。
标签:cow,bluestore,chunk,write,io,small,对齐,clone,size 来源: https://blog.csdn.net/qq_23929673/article/details/104033338