linux内核源码翻阅之facebook硬盘加速利器flashcache
linux内核源码阅读之facebook硬盘加速利器flashcache从来没有写过源码阅读，这种感觉越来越强烈，虽然劣于文
linux内核源码阅读之facebook硬盘加速利器flashcache
从来没有写过源码阅读，这种感觉越来越强烈，虽然劣于文笔，但还是下定决心认真写一回。源代码下载请参见上一篇flashcache之我见 http://blog.csdn.net/liumangxiong/article/details/11643473下面代码对应的是tag下面的1.0版本的。
看内核模块源码，闭着眼睛打开flashcache_init函数，区区百来行代码何足惧也。
/* * We have one of these for *every* cache metadata sector, to keep track * of metadata ios in progress for blocks covered in this sector. Only * one metadata IO per sector can be in progress at any given point in * time */struct cache_md_sector_head {u_int32_tnr_in_prog;struct kcached_job*pending_jobs, *md_io_inprog;};按规矩先看注释，每一个cache metadata扇区都有对应一个cache_md_sector_head结构，用于同步进程（内存中）cacheblock metadata到cache metadata扇区。同时只能有一个IO在同步，对应的是cache_md_sector_head->nr_in_prog。回答上面的问题，就是这些kcached_job是对应同一个扇区内的不同metadata的写，所以可以合并。这个扇区指的是SSD盘上存放flash_block结构的。再回到flashcache_md_write_done函数中，在for循环中job->action为WRITEDISK，所以直接来到for循环中else，迎面而来的又是一行注释，在WRITEDISK*发生错误时，只有保持cacheblock的DIRTY标志。接下来判断有错误或者cacheblock上还有pending_job，那么继续下发IO，否则的话清除cacheblock的处理标志，这里我们终于见到了kcached_job完成了他的使命，调用flashcache_free_cache_job将该结构返回给内存池。似乎到这里我们就可以像童话里讲的“从此他们过上了幸福的生活”来结束kcached_job的介绍。然而回归资源池也意味着kcached_job的再生，接着判断action==WRITEDISK，调用flashcache_clean_set，将超过脏水平线的cache块刷回到磁盘。就是说在每次写磁盘返回的时候这个workqueue都会检查一下脏水平线，如果超过就继续往下刷，这就又回到了本文最开始的flashcache_dirty_writeback函数，真是因果联系，环环相扣，kcached_job的再生不是为了自己，而是为cacheblock的再生，所以说人不能只为自己活着，每个人只是万千轮回里的一个元素，都是为了成全其他元素而进入六道轮回。下面一篇会从flashcache的数据结构和存储设计来分析。
