前言所谓吃一堑长一智，每次面对问题才是最好的学习机会，在面对问题的时候，尽量是能够自己去解决，或者去尝试能够最接近答案，确实无法解决再去寻求他人帮助，这样成长的会更快一些，在学校读书做题的时候，老师也是经常告诉我们要忍住，不要去直接翻答案，在当今的互联网飞速的发展下，在google的帮助下，基本上90%的问题都能找到正确的答案，而我们其实真正需要锻炼的是实践能力和甄别的能力 去年一年给不少的生产环

引言我们在进行 ceph 的 osd 的增加和减少的维护的时候，会碰到迁移数据，但是我们平时会怎么去回答关于迁移数据量的问题，一般来说，都是说很多，或者说根据环境来看，有没有精确的一个说法，到底要迁移多少数据?这个我以前也有思考过这个问题，当时想是对比前后的pg的分布，然后进行计算，正好在翻一些资料的时候，看到有alram写的一篇博客，alram是Inktank的程序员，也就是sage所在的公司，

前言如果你有订阅一些科技新闻，应该会有看过内核在4.9当中加入了一个新的算法，来解决在有一定的丢包率的情况下的带宽稳定的问题，这个是谷歌为我们带来的干货，新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT)，谷歌一向的做法是，先上生产，然后发论文，然后有可能开源，所以这个已经合并到了内核4.9分支当中，算法带来的改变在出的测试报告当中有很详细的数据展示，

前言RBD 的 mirroring 功能将在Jewel中实现的，这个Jewel版本已经发布了很久了,这个功能已经在这个发布的版本中实现了，本来之前写过一篇文章，但是有几个朋友根据文档配置后，发现还是有问题，自己在进行再次配置的时候也发现有些地方没讲清楚，容易造成误解，这里对文档进行再一次的梳理 基本原理我们试图解决的或者至少需要克服的问题是，ceph在内部是强一致性的，这个对于跨区域的情况数据同步

teralytics是一家国外的大数据公司，这个是他们开源的ceph的备份的工具，在twitter上搜索相关信息的时候看到，觉得不错就拿来试用一番 这是个什么软件一个用来备份 ceph 的 rbd 的image的开源软件，提供了两种模式增量：在给定备份时间窗口内基于 rbd 快照的增量备份完全：完整镜像导出时不包含快照 注意一致性：此工具可以生成 rbd 镜像的快照，而不会感知到它们的文件系统的

问题flag sortbitwise 在ceph中是什么意思,在Jewel版本下可以看到多了这个flags 1234567891011[root@lab8106 current]# ceph -s cluster ffe7a8db-c671-4b45-a784-ddb41e633905 health HEALTH_OK monmap e1: 1 mons at {l

前言一直在做calamari的相关的一些打包和安装的工作，都是业余弄的东西，所以并没有仔细的进行功能点的验证测试，正好ceph社区群里面有人问了个问题 calamari上是不是能看到ceph的version? 对于这个问题，好像确实没有见到过，而之前正好有个页面看到是空的，当时还不清楚这个是什么用的 而另外一位群友贴出了这个地方的是有值的，这个地方是有BUG的，在咨询了相关的问题描述以后，

很多年以前，Sage 在写CRUSH的原始算法的时候，写了不同的Bucket类型，可以选择不同的伪随机选择算法，大部分的模型是基于RJ Honicky写的RUSH algorithms 这个算法，这个在网上可以找到资料，这里面有一个新的特性是sage很引以为豪的，straw算法，也就是我们现在常用的一些算法，这个算法有下面的特性： items 可以有任意的weight 选择一个项目的算法复杂度是

总结了几个小技巧，用于在ceph编译过程中，能够更快一点 修改clone的地址 git clone https://github.com/ceph/ceph.git 可以修改成 git clone git://github.com/ceph/ceph.git 某些时候可能可以加快一些 根据需要下载分支假如现在想看10.2.5版本的代码 常规做法先

前言收到一个问题如下： 一个300TB 的RBD，只有7800万的objects，如果存储小文件的话，感觉不够用 对于这个问题，我原来的理解是：对象默认设置的大小是4M一个，存储下去的数据，如果小于4M，就会占用一个小于4M的对象，如果超过4M，那么存储的数据就会进行拆分成多个4M，这个地方其实是不严谨的 对于rados接口来说，数据是多大对象put进去就是多大的对象，并没有进行拆分，进行拆