前言这个问题的来源是ceph社区里面一个群友的环境出现在85%左右的时候，启动osd报错，然后在本地文件系统当中进行touch文件的时候也是报错，df -i查询inode也是没用多少，使用的也是inode64挂载的，开始的时候排除了配置原因引起的，在ceph的邮件列表里面有一个相同问题，也是没有得到解决 看到这个问题比较感兴趣，就花了点时间来解决来定位和解决这个问题，现在分享出来，如果有类似的生产

前言碰到一个cepher问了一个问题： 为什么我的OSD关闭到最后有92个OSD无法关闭,总共的OSD有300个左右 想起来在很久以前帮人处理过一次问题，当时环境是遇上了一个BUG，需要升级到新版本进行解决，然后当时我来做操作，升级以后，发现osd无法启动，进程在，状态无法更新，当时又回滚回去，就可以了，当时好像是K版本升级到J版本，想起来之前看过这个版本里面有数据结构的变化，需要把osd全部

前言关于scrub这块一直想写一篇文章的，这个在很久前，就做过一次测试，当时是看这个scrub到底有多大的影响，当时看到的是磁盘读占很高，启动deep-scrub后会有大量的读,前端可能会出现 slow request,这个是当时测试看到的现象，一个比较简单的处理办法就是直接给scrub关掉了，当然关掉了就无法检测底层到底有没有对象不一致的问题关于这个scrub生产上是否开启，仁者见仁，智者见智，

前言这个工具我第一次看到是在填坑群里面看到，是由研发-北京-蓝星同学分享的，看到比较有趣，就写一篇相关的记录下用法 火焰图里面也可以定位内存方面的问题，那个是通过一段时间的统计，以一个汇总的方式来查看内存在哪个地方可能出了问题 本篇是另外一个工具，这个工具的好处是有很清晰的图表操作，以及基于时间线的统计，下面来看下这个工具怎么使用的 本篇对具体的内存函数的调用占用不会做更具体的分析，这里是提供一

前言磁盘损坏对于一个大集群来说，可以说是必然发生的事情，即使再小的概率，磁盘量上去，总会坏那么几块盘，这个时候就会触发内部的修复过程，修复就是让不满足副本要求的PG，恢复到满足的情况 一般是踢掉坏盘和增加新盘会触发这个修复过程，或者对磁盘的权重做了修改，也会触发这个迁移的过程，本篇是用剔除OSD的方式来对这个修复的控制做一个探索 大部分场景下要求的是不能影响前端的业务，而加速迁移，忽略迁移影响不在

前言ceph的s3数据的同步可以通过radosgw-agent进行同步，同region可以同步data和metadata，不同region只能同步metadata，这个地方可以参考下秦牧羊梳理的 ceph radosgw 多集群同步部署流程，本篇讲述的方案与radosgw-agent的复制方案不同在于,这个属于前端复制，后端相当于透明的两个相同集群，在入口层面就将数据进行了复制分流 在某些场景下，

前言这个问题在很久以前就有一篇文章进行过讨论 remove-big-rbd,这个文章写的比较清楚了，并且对不同的方法做了分析，这里先把结论说下 rbd类型 rbd rm 方法 rados -p rm方法 未填充很多 慢 快 已填充很多 快 慢 在rbd进行删除的时候，即使内部没有对象数据，也一样需要一个个对象去发请求，即使对象不存在，这个可以开日志看到 实验过程开启日志的方

前言之前有个想法，是不是有办法找到rbd中的文件与对象的关系，想了很久但是一直觉得文件系统比较复杂，在fs 层的东西对ceph来说是透明的，并且对象大小是4M，而文件很小，可能在fs层进行了合并，应该很难找到对应关系，最近看到小胖有提出这个问题，那么就再次尝试了，现在就是把这个实现方法记录下来 这个提取的作用个人觉得最大的好处就是一个rbd设备，在文件系统层被破坏以后，还能够从rbd提取出文件，

前言性能优化大神Brendan Gregg发明了火焰图来定位性能问题，通过图表就可以发现问题出在哪里，通过svg矢量图来查看性能卡在哪个点，哪个操作占用的资源最多 在查看了原始数据后，这个分析的原理是按层级来对调用进行一个计数，然后以层级去做比对，来看横向的占用的比例情况 基于这个原理，把osd tree的数据和pg数据可以做一个层级的组合，从而可以很方便的看出pg的分布情况，主机的分布情况，还可

前言文件系统当中如果某些文件不见了，有什么办法判断是删除了还是自己不见了，这个就需要去日志里面定位了，通常情况下是去翻日志，而日志是会进行压缩的，并且查找起来非常的不方便,还有可能并没有开启 这个时候就需要日志系统了，最近正好看到一篇最佳日志实践（v2.0），一篇非常好的文章，本篇日志属于文章里面所提到的统计日志，统计客户端做了什么操作 对于日志系统来说，很重要的一点，能够很方便的进行查询，这就需