linux内核源码阅读之facebook硬盘加速flashcache之三
上一节讲到在刷缓存的时候会调用new_kcahed_job创建kcached_job，由此我们也可以看到cache数据块与磁盘数据的对应关系。上一篇：http://blog.csdn.net/liumangxiong/article/details/11726651现在继续从new_kcached_job函数中挖掘有用的信息。那就是cache块跟磁盘上扇区是怎么对应起来的？即329行的为什么要写的disk.sector是后面这个值呢？ job->disk.sector = dmc->cache[index].dbn;
最这里是时候揭开变量dmc也就是结构体struct cache_c的真面目了。dmc可以理解成device mapper context或者device mapper cache。先看struct cache_c
344/* 345 * We have one of these for *every* cache metadata sector, to keep track346 * of metadata ios in progress for blocks covered in this sector. Only347 * one metadata IO per sector can be in progress at any given point in 348 * time349 */350struct cache_md_sector_head {351u_int32_tnr_in_prog;352struct kcached_job*pending_jobs, *md_io_inprog;353};看注释，每一个cache metadata扇区对应一个struct cache_md_sector_head结构，用以追踪这个扇区上的IO，这个扇区的IO来自该扇区对应的每一个cache块的状态变化。每一次只允许一个IO在下发。在初始化时，nr_in_prog为0，两个队列也都为零。其中的一个cache块发生变化并且状态要更新到SSD中，这时创建一个job并挂入到pending_jobs，下发时将nr_in_prog置为1，并将job从pending_jobs移到md_io_inprog，如果job下发过程中又有其他job下发，就挂到pending_jobs，等md_io_inprog处理完成再继续下一次下发过程。到这里，我们把flashcache重要的数据结构都过了一遍。下一节开始介绍flashcache的数据流。