zoukankan      html  css  js  c++  java
  • rbd的image对象数与能写入文件数的关系

    前言

    收到一个问题如下:

    一个300TB 的RBD,只有7800万的objects,如果存储小文件的话,感觉不够用

    对于这个问题,我原来的理解是:对象默认设置的大小是4M一个,存储下去的数据,如果小于4M,就会占用一个小于4M的对象,如果超过4M,那么存储的数据就会进行拆分成多个4M,这个地方其实是不严谨的

    对于rados接口来说,数据是多大对象put进去就是多大的对象,并没有进行拆分,进行拆分的是再上一层的应用,比如rbd,比如cephfs

    那么对于rbd的image显示的对象数目和文件数目有什么关系呢?本篇将来看看这个问题,到底会不会出现上面的问题

    实践过程

    创建一个image

    [root@lab8106 ~]# rbd create --image zpsize --size 100M
    [root@lab8106 ~]# rbd info zpsize
    rbd image 'zpsize':
    	size 102400 kB in 25 objects
    	order 22 (4096 kB objects)
    	block_name_prefix: rbd_data.85c66b8b4567
    	format: 2
    	features: layering
    	flags: 
    

    可以看到,这个image从集群中分配到了25个对象,每个对象的大小为4M,假如我们写入1000个小文件看下会是什么情况

    映射到本地并且格式化xfs文件系统

    [root@lab8106 ~]# rbd map zpsize
    /dev/rbd0
    [root@lab8106 ~]# mkfs.xfs -f /dev/rbd0 
    meta-data=/dev/rbd0              isize=256    agcount=4, agsize=6144 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=0        finobt=0
    data     =                       bsize=4096   blocks=24576, imaxpct=25
             =                       sunit=1024   swidth=1024 blks
    naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
    log      =internal log           bsize=4096   blocks=624, version=2
             =                       sectsz=512   sunit=8 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    

    挂载到本地
    [root@lab8106 ~]# mount /dev/rbd0 /mnt

    写入1000个1K小文件

    [root@lab8106 ~]# seq 1000|xargs -i dd if=/dev/zero of=/mnt/a{} bs=1K count=1
    

    没有报错提示,正常写入了,我们看下写入了多少对象

    [root@lab8106 ~]# rados  -p rbd ls|grep rbd_data.85c66b8b4567
    rbd_data.85c66b8b4567.0000000000000018
    rbd_data.85c66b8b4567.0000000000000000
    rbd_data.85c66b8b4567.0000000000000006
    rbd_data.85c66b8b4567.0000000000000001
    rbd_data.85c66b8b4567.0000000000000017
    rbd_data.85c66b8b4567.000000000000000c
    rbd_data.85c66b8b4567.0000000000000012
    rbd_data.85c66b8b4567.0000000000000002
    

    只写入了少量的对象,我们尝试下载下来看看

    [root@lab8106 ~]# ll -hl rbd_data.85c66b8b4567.0000000000000018
    -rw-r--r-- 1 root root 4.0M Jan  3 14:27 rbd_data.85c66b8b4567.0000000000000018
    [root@lab8106 ~]# rados  -p rbd get rbd_data.85c66b8b4567.0000000000000000 rbd_data.85c66b8b4567.0000000000000000
    [root@lab8106 ~]# ll -hl rbd_data.85c66b8b4567.0000000000000000
    -rw-r--r-- 1 root root 4.0M Jan  3 14:27 rbd_data.85c66b8b4567.0000000000000000
    

    可以看到还是4M的对象,实际上写入的小文件已经进行了合并了,在底层已经是一个4M的对象文件了

    总结

    本篇的结论就是,rbd层之上的写入的文件的个数与底层的对象数目是没有关系的,对象数目和对象大小是底层处理的,再上一层就是文件系统去处理的了,总空间占用上是一致的

  • 相关阅读:
    每天改进一点点之改进日志收集系统 原创: 赵建鹏 雪球工程师团队 2018-03-23
    Locust
    ('' or 60)
    python动态获取对象的属性和方法 (转载)
    MySQL 8.0: From SQL Tables to JSON Documents (and back again)
    词典型 遍历键 顺序
    子系统权限栏目 自己生成 自己控制
    Redis 单线程却能支撑高并发
    OPPO数据中台之基石:基于Flink SQL构建实数据仓库
    技术干货丨如何在VIPKID中构建MQ服务
  • 原文地址:https://www.cnblogs.com/zphj1987/p/13575400.html
Copyright © 2011-2022 走看看