去年上半年公司大佬提到了一个内核研究课题，但当时项目组没有对应的经验人士，临时投入远水不能解近渴，便和某著名工科大学linux实验室进行一次项目研究。前期是师兄带队跟踪这个项目研究，后期便让我跟这个项目，直到项目结题。 我8个月时间便投入了这次技术研究项目中，虽然最终课题顺利结题，但研究结果还是差强人意...

产品的老大直接找到了我：他们对reiserfs的一个分区写文件数据时返回失败，返回值是28，既是No space left on device，直接到产品环境上一看，12TB的空间用了不到10GB，自己顿时头大了，我一直对“设计精妙，代码残废”的reiserfs心怀敬畏（首席设计人员中途溜号，后面全靠开发人员脑补的复杂工程真是灾难），恰好还有其他...

这两天忙着定位一个reiserfs文件系统的问题，事情确是很简单：产品的服务器在测试业务时直接将服务器暴力下电了，结果挂载的磁阵就悲剧了，业内所知受部门物料成本限制，实验室的环境都是拼凑的，很神奇的是这个磁阵的电池被拔掉了，再次上电的时候OS就很规律的7min oops一次，问题很快（内核panic）就送到了额们组。当...

SSD损坏的原因是一个点写的次数过多了，优化的方式就是减少总的写入量。 1.更改BLOS中磁盘读写设置为AHCI，改为顺序写，提高读写效率 2.将SSD分一个区，如果是多个区就要注意文件系统的块开头和SSD的块开通对齐，否则就会文件系统的一个块写转换成硬件就是两个块写，是为骑马。 3.更改系统挂载文件/etc/fs...