前言mds是ceph里面处理文件接口的组件，一旦使用文件系统，不可避免的会出现一种场景就是目录很多，目录里面的文件很多，而mds是一个单进程的组件，现在虽然有了muti mds，但稳定的使用的大部分场景还是单acitve mds的 这就会出现一种情况，一旦一个目录里面有很多文件的时候，去查询这个目录里的文件就会在当前目录做一次遍历，这个需要一个比较长的时间，如果能比较好的缓存文件信息，也能避免一些

前言博客很久没有更新了，一个原因就是原来存放部署博客的环境坏了，硬盘使用的是SSD，只要读取到某个文件，整个磁盘就直接识别不到了，还好博客环境之前有做备份，最近一直没有把部署环境做下恢复，今天抽空把环境做下恢复并且记录一篇基础的GRUB的处理文档 这两天正好碰到GRUB损坏的事，很久前处理过，但是没留下文档，正好现在把流程梳理一下，来解决grub.cfg损坏的情况,或者无法启动的情况 实践步骤安装

前言本篇讲述的是一个比较极端的故障的恢复场景，在整个集群全部服务器突然掉电的时候，osd里面的osdmap可能会出现没刷到磁盘上的情况，这个时候osdmap的最新版本为空或者为没有这个文件 还有一种情况就是机器宕机了，没有马上处理，等了一段时间以后，服务器机器启动了起来，而这个时候osdmap已经更新了，全局找不到需要的旧版本的osdmap和incmap，osd无法启动 一般情况下能找到的就直接从

前言本篇来源于群里一个人的问题，有没有办法让ceph的磁盘不自动挂载，一般人的问题都是怎样让ceph能够自动挂载，在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的，这个我之前也写过两篇文章《ceph在centos7下一个不容易发现的改变》和《Ceph数据盘怎样实现自动挂载》，来讲述这个自动挂载的 这里讲下流程： 开机后 udev 匹配 95-ceph-osd.rul

前言服务器上面的服务会因为各种各样的原因失败，磁盘故障，权限问题，或者是服务过载引起超时，这些都可能引起 这个在ceph里面systemctl unit 默认有个on-fail restart,默认的可能并不适合所有的场景，所以自动化的服务应该是尽量去适配你手动处理的过程，手动怎么处理的，就怎么去设置 启动分析如果有osd失败了，一般上去会先启动一次，尽快让服务启动，然后去检查是否有故障，如果失败

前言这个问题的来源是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的方式来对这个修复的控制做一个探索 大部分场景下要求的是不能影响前端的业务，而加速迁移，忽略迁移影响不在