Always look out for number one.

常用 mdadm 命令生成配置文件mdadm.confcp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.save/usr/share/mdadm/mkconf --generate > /etc/mdadm/mdadm.conf创建RAIDmdadm --create /dev/md2 --raid-devices=3

linux内核奇遇记之md源代码解读之五转载请注明出处：http://blog.youkuaiyun.com/liumangxiong如果看懂了raid1阵列的run函数，那么看raid5阵列run就非常轻松了，因为两者要做的事情都是大同小异。raid5的run函数很长，但很大一部分跟创建运行是没有关系的，特别是有一段跟reshape相关的，大多数系统都不关注该功能，因此可以直接跳过。经过删减

linux内核奇遇记之md源代码解读之六转载请注明出处：http://blog.youkuaiyun.com/liumangxiongraid10的run函数与raid5的run函数最大区别在于setup_conf，那就直接深入核心：3540 static struct r10conf *setup_conf(struct mddev *mddev)3541 {3542

linux内核奇遇记之md源代码解读之八阵列同步二转载请注明出处：http://blog.youkuaiyun.com/liumangxiong在上一小节里讲到启动同步线程：7824 mddev->sync_thread = md_register_thread(md_do_sync,7825

linux内核奇遇记之md源代码解读之七阵列同步一转载请注明出处：http://blog.youkuaiyun.com/liumangxiong阵列同步在md_do_sync，那么入口在哪里呢？就是说阵列同步触发点在哪里呢？听说过md_check_recovery吧，但这还不是同步的入口点。那raid5d函数是入口点吧？如果要认真分析起来还不算是。真正的同步入口点在do_md_run函数，就是在运

linux内核奇遇记之md源代码解读之九阵列raid5同步函数sync_request转载请注明出处：http://blog.youkuaiyun.com/liumangxiong我们再来回顾一下整个场景：1）在运行阵列的时候调用md_wakeup_thread唤醒主线程2）主线程调用md_check_recovery检查同步3）md_check_recovery函数中检查需要同步调用

linux内核奇遇记之md源代码解读之十一raid5d转载请注明出处：http://blog.youkuaiyun.com/liumangxiong正是有了上一篇的读写基础，我们才开始看raid5d的代码。raid5d不是读写的入口，也不是读写处理的地方，只是简简单单的中转站或者叫做交通枢纽。这个枢纽具有制高点的作用，就像美国在新加坡的基地，直接就控制了太平洋和印度洋的交通枢纽。4626 /*

linux内核奇遇记之md源代码解读之十二raid读写转载请注明出处：http://blog.youkuaiyun.com/liumangxiong我们都知道，对一个linux块设备来说，都有一个对应的请求队列。注册在这个请求队列上的请求就是该块设备的请求入口。对于raid来说，分配struct mddev时就已经设置好了，在函数md_alloc中有这样的代码：4846 blk_que

linux内核奇遇记之md源代码解读之十raid5数据流之同步数据流程 转载请注明出处：http://blog.youkuaiyun.com/liumangxiong上一节讲到在raid5的同步函数sync_request中炸土豆片是通过handle_stripe来进行的。从最初的创建阵列，到申请各种资源，建立每个阵列的personality，所有的一切都是为了迎接数据流而作的准备。就像我们寒窗苦

linux内核奇遇记之md源代码解读之十三raid5重试读转载请注明出处：http://blog.youkuaiyun.com/liumangxiong上节我们讲到条块内读失败，在回调函数raid5_align_endio中将请求加入阵列重试链表，在唤醒raid5d线程之后，raid5d线程将该请求调用retry_aligned_read函数进行重试读：4539static int re

从原理上讲，raid5出现坏块之后读操作肯定是会绕道读取的。我用设置/sys/block/md1/md/dev-sdb/bad_blocks的方法来模块磁盘坏块，用dd从md读数据，从iostat查看的数据流。创建一个三个盘的raid5： Number Major Minor RaidDevice State 0 8 80

linux内核奇遇记之md源代码解读之十四raid5非条块内读如果是非条块内读，那么就至少涉及到两个条块的读，这就需要分别从这两个条块内读出数据，然后再凑成整个结果返回给上层。接下来我们将看到如何将一个完整的bio读请求拆分成多个子请求下发到磁盘，从磁盘返回之后再重新组合成请求结果返回给上层的。4097 logical_sector = bi->bi_sector & ~((sec

linux内核奇遇记之md源代码解读之四转载请注明出处：http://blog.youkuaiyun.com/liumangxiong运行阵列意味着阵列经历从无到有，建立了作为一个raid应有的属性（如同步重建），并为随后的读写做好的铺垫。那么运行阵列的时候到底做了哪些事情，让原来的磁盘像变形金刚一样组成一个新的巨无霸。现在就来看阵列运行处理流程：5158 static int do_md

linux内核奇遇记之md源代码解读之三转载请注明出处：http://blog.youkuaiyun.com/liumangxiong这一节我们阅读阵列的创建过程。按照常理出牌，我们到ioctl中找阵列创建命令，md对应的ioctl函数是md_ioctl，当找对应的cmd命令字时，却完全没有类似CREATE_ARRAY的命令，那么就说明md设备并不是通过ioctl函数来创建的。其实如果我们仔细

这个星期偷着点闲看下flashcache，所谓知其然知其所以然，本着程序员追根抛底的职业素养，看看flashcache究竟是何等的三头六臂。一、flashcache是什么flashcache是一个linux内核模块，主要目的是用SSD加速块设备，相当于用SSD盘作为块设备的缓存。二、flashcache在内核的哪一层位于内核的dm层（device mapper)，在块设备之上，在V

linux内核函数之 blk_plug

flashcache数据结构都在flashcache.h文件中，但在看数据结构之前，需要先过一遍flashcache是什么，要完成哪些功能？如果是自己设计这样一个系统的话，大概要怎么设计。前面讲过，flashcache主要用途还是在写缓存上，要写入磁盘的IO先写入速度较快的SSD盘，随后再由单独的线程将SSD盘中脏数据块同步到磁盘中。这样看来，SSD就是一个缓存，有缓存的基本特性如命中、脏、水

上一节讲到在刷缓存的时候会调用new_kcahed_job创建kcached_job，由此我们也可以看到cache数据块与磁盘数据的对应关系。上一篇：http://blog.youkuaiyun.com/liumangxiong/article/details/11726651现在继续从new_kcached_job函数中挖掘有用的信息。那就是cache块跟磁盘上扇区是怎么对应起来的？即329行的为什么要

从来没有写过源码阅读，这种感觉越来越强烈，虽然劣于文笔，但还是下定决心认真写一回。源代码下载请参见上一篇flashcache之我见 http://blog.youkuaiyun.com/liumangxiong/article/details/11643473下面代码对应的是tag下面的1.0版本的。看内核模块源码，闭着眼睛打开flashcache_init函数，区区百来行代码何足惧也。

正常流程到flashcache_map的1623行或1625行，按顺序先看读流程：1221static void1222flashcache_read(struct cache_c *dmc, struct bio *bio)1223{1224 int index;1225 int res;1226 struct cacheblock *cacheblk;1227 int qu

这一小节介绍一下flashcache读写入口和读写的基础实现。首先，不管是模块还是程序，必须先找到入口，用户态代码会经常去先看main函数，内核看module_init，同样看IO流时候也要找到入口。flashcache作为一个dm_target，入口就是struct target_type 的map函数，对应的是flashcache_map函数：1581/*1582 * Decid

其实到目前为止，如果对读流程已经能轻松地看懂了，那么写流程不需要太多脑细胞。我觉得再写下去没有太大的必要了，后面想想为了保持flashcache完整性，还是写出来吧。接着到写流程：1530static void1531flashcache_write(struct cache_c *dmc, struct bio *bio)1532{1533 int index;1534

这一节讲缓存的写回磁盘流程。这里隆重介绍一下两位幕后的英雄：1724/*1725 * Sync all dirty blocks. We pick off dirty blocks, sort them, merge them with1726 * any contigous blocks we can within the set and fire off the writes.1

前面我们的分析中重点关注正常的数据流程，这一小节关注如果有异常，那么流程是怎么走完的呢？1）创建新任务时kcached_job申请不到2）读写命中时cache块为忙3）系统关机时处理，系统开机时处理，系统异常掉电后的处理首先来看第1种情况，申请kcached_job是在函数flashcache_lookup中，543/* 544 * dbn is the starting

linux内核奇遇记之md源代码解读之一转载请注明出处：http://blog.youkuaiyun.com/liumangxiong最近花了一段时间认真地学习了一下md代码，并且在原代码的基础上开发了一系列的新功能，这些新功能让md更完善、更适合于企业大容量存储，通过增加阵列缓存和bitmap优化大大提升了存储速度，提高了数据的可靠性，在任何掉电的情况下保证数据一致性，超级块异常情况下完全不影响

linux内核奇遇记之md源代码解读之二转载请注明出处：http://blog.youkuaiyun.com/liumangxiong在编译完成linux内核源代码的时候，drivers/md目录下会生成多个ko文件，那么这些内核模块哪一个先加载，哪一个后加载的呢？例如md-mod.ko, raid5.ko, raid10.ko，这些模块是一起加载的呢，还是有先后顺序呢？如果熟悉linux内核编程的话

linux内核奇遇记之md源代码解读之十五bitmap原理转载请注明出处：http://blog.youkuaiyun.com/liumangxiong 为人不识陈近南，走遍江湖也枉然。做raid不识bitmap，通通都是走过场。那么bitmap究竟是何许人物，能够在raid5的场子里混得风生水起呢？话说最早raid5是没有bitmap这位门客的，突然有一天跑raid5的系统异常掉电了，客户发