最近想学习Linux IO子系统, 找了flashcache代码, 它通过内核提供的Device Mapper机制, 将一块SSD和一块普通磁盘虚拟为一个块设备, 其中SSD作为cache, 数据最终落地到普通磁盘. 这种混合存储的策略, 向上层应用(如mysql)屏蔽了底层的实现, 上层应用看到的只是一个挂载到虚拟块设备上的某种文件系统, 使用常见的文件系统接口即可读写数据, 一方面保持兼容, 一方面获得不错的性能. flashcache的代码只有几千行, 从commit log中可以看到版本迭代比较频繁, 也因此引入了较多我个人不关心的新特性. flashcache源码中作者写到借鉴了dm-cache的代码, 所以查了下资料, 竟是国人出品, sloc不足两千, 一晚上就可以看完, 正合胃口. dm-cache的使用可以参考flashcache文档, 原理见flashcache原理.
内存结构
dm-cache思路非常简单, 它把SSD作为cache, 将数据持久化到普通磁盘. 其中, SSD cache组织方式为set-associative map, 这和CPU cache的组织非常相像, 只是这里的key是cacheblock编号. cacheblock是dm-cache为了方便存取数据引入的单位, 粒度在磁盘block之上. 在通过dmsetup创建dm-cache块设备时时可以指定cacheblock的大小, 默认为8个连续的磁盘block组成一个cacheblock, 即4k字节. 上层的IO请求由Device Mapper框架切割为cacheblock大小(且对齐)的bio, 然后交由dm-cache处理. 也就是说, 不管是对SSD, 还是普通磁盘, dm-cache处理IO的单位都是cacheblock. 它在内存中的metadata为:
117 /* Cache block metadata structure */
118 struct cacheblock {
119 spinlock_t lock; /* Lock to protect operations on the bio list */
120 sector_t block; /* Sector number of the cached block */
121 unsigned short state; /* State of a block */
122 unsigned long counter; /* Logical timestamp of the block's last access */
123 struct bio_list bios; /* List of pending bios */
124 };
其中, block字段表示当前cacheblock的起始扇区编号. 既然SSD作为cache, 针对写请求必定会有writeback和writethrough等多种选择. writeback即数据先写到SSD, 然后由后台线程在合适的时间写回磁盘. writethrough指数据同时写入磁盘和SSD. (flashcache在这基础上又增加了writearound的方式, 意思是绕过SSD cache, 数据直接写入磁盘, 在处理读请求时更新到SSD.) 不管是writeback, 还是writethrough, 数据写入磁盘(或者由磁盘读取数据更新至cache)都不可能一蹴而就, 所以每个cacheblock必定会有一个状态(state字段). 另外, cache有淘汰的概念, dm-cache支持FIFO或LRU淘汰, 所以需要为每个cacheblock保存其最后访问时间(counter字段). 最后, 为了互斥同时请求同一个cacheblock, 每个cacheblock还对应一个spinlock. 被互斥的后发请求记录在bios链表中. 在当前cacheblock上的操作完成后, dm-cache将重新提交bios链表上的bio.
接下来看下dm-cache的总控结构体cache_c:
80 /*
81 * Cache context
82 */
83 struct cache_c {
84 struct dm_dev *src_dev; /* Source device */
85 struct dm_dev *cache_dev; /* Cache device */
86 struct dm_kcopyd_client *kcp_client; /* Kcopyd client for writing back data */
87
88 struct cacheblock *cache; /* Hash table for cache blocks */
89 sector_t size; /* Cache size */
90 unsigned int bits; /* Cache size in bits */
91 unsigned int assoc; /* Cache associativity */
92 unsigned int block_size; /* Cache block size */
93 unsigned int block_shift; /* Cache block size in bits */
94 unsigned int block_mask; /* Cache block mask */
95 unsigned int consecutive_shift; /* Consecutive blocks size in bits */
96 unsigned long counter; /* Logical timestamp of last access */
97 unsigned int write_policy; /* Cache write policy */
98 sector_t dirty_blocks; /* Number of dirty blocks */
99
100 spinlock_t lock; /* Lock to protect page allocation/deallocation */
101 struct page_list *pages; /* Pages for I/O */
102 unsigned int nr_pages; /* Number of pages */
103 unsigned int nr_free_pages; /* Number of free pages */
104 wait_queue_head_t destroyq; /* Wait queue for I/O completion */
105 atomic_t nr_jobs; /* Number of I/O jobs */
106 struct dm_io_client *io_client; /* Client memory pool*/
107
108 /* Stats */
109 unsigned long reads; /* Number of reads */
110 unsigned long writes; /* Number of writes */
111 unsigned long cache_hits; /* Number of cache hits */
112 unsigned long replace; /* Number of cache replacements */
113 unsigned long writeback; /* Number of replaced dirty blocks */
114 unsigned long dirty; /* Number of submitted dirty blocks */
115 };
其中, src_dev和cache_dev分别为磁盘和SSD在DM框架的抽象. cache字段为连续的cacheblock数组, 元素个数即size字段. 其余字段顾名思义, 不再赘述.
初始化
dm-cache的初始化代码相对简单, DM框架获取dmsetup参数, 传递给cache_ctr(), dm-cache通过该函数构造一个cache_c对象, 保存在dm_target.private中. dm_target结构中另一重要字段为split_io, 这个字段表示DM框架分割bio的粒度, cache_ctr()函数指定其为cacheblock大小.
上层的读写请求在IO内核路径上表示为bio, 针对Device Mapper框架虚拟出来的块设备的bio请求, DM框架通过bio的block编号找到所属的dm_targets(一个bio的请求可能横跨多个dm_target), 逐个回调dm_target.type->map, 该字段为函数指针, 在dm-cache模块加载到内核时, 由该模块的初始化函数dm_cache_init()注册为cache_map(). 也就是说, 读写请求的入口都是cache_map().
请求处理
如上所述, 读写请求的入口都是cache_map(), 其实现如下:
1202 /*
1203 * Decide the mapping and perform necessary cache operations for a bio request.
1204 */
1205 static int cache_map(struct dm_target *ti, struct bio *bio,
1206 union map_info *map_context)
1207 {
1208 struct cache_c *dmc = (struct cache_c *) ti->private;
1209 sector_t request_block, cache_block = 0, offset;
1210 int res;
1211
1212 offset = bio->bi_sector & dmc->block_mask;
1213 request_block = bio->bi_sector - offset;
1214
1220 if (bio_data_dir(bio) == READ) dmc->reads++;
1221 else dmc->writes++;
1222
1223 res = cache_lookup(dmc, request_block, &cache_block);
1224 if (1 == res) /* Cache hit; server request from cache */
1225 return cache_hit(dmc, bio, cache_block);
1226 else if (0 == res) /* Cache miss; replacement block is found */
1227 return cache_miss(dmc, bio, cache_block);
1228 else if (2 == res) { /* Entire cache set is dirty; initiate a write-back */
1229 write_back(dmc, cache_block, 1);
1230 dmc->writeback++;
1231 }
1232
1233 /* Forward to source device */
1234 bio->bi_bdev = dmc->src_dev->bdev;
1235
1236 return 1;
1237 }
该函数首先从ti->private中获取cache_c *dmc, 这个对象由cache_ctr()中构造. 接着获得bio所请求的起始扇区(即bio->bi_sector)所属的cacheblock的扇区编号, 保存在request_block变量. 接着通过cache_lookup()函数在dmc->cache中查找, key便是request_block. cache_lookup()代码相对简单, 不再细述.
如果cache中查找失败, 则进入cache_miss()逻辑. 其最后一个参数cache_block为cache_lookup()以某种淘汰形式找到的待替换的cacheblock的扇区编号.
1189 /* Handle cache misses */
1190 static int cache_miss(struct cache_c *dmc, struct bio* bio, sector_t cache_block) {
1191 if (bio_data_dir(bio) == READ)
1192 return cache_read_miss(dmc, bio, cache_block);
1193 else
1194 return cache_write_miss(dmc, bio, cache_block);
1195 }
cache_miss()函数判断bio是读是写, 读则调用cache_read_miss(), 否则调用cache_write_miss().
篇幅所限, 接下来我们只看下读请求未命中cache的情况, 这时cache_read_miss()将被调用.
1073 /*
1074 * Handle a read cache miss:
1075 * Update the metadata; fetch the necessary block from source device;
1076 * store data to cache device.
1077 */
1078 static int cache_read_miss(struct cache_c *dmc, struct bio* bio,
1079 sector_t cache_block) {
1080 struct cacheblock *cache = dmc->cache;
1081 unsigned int offset, head, tail;
1082 struct kcached_job *job;
1083 sector_t request_block, left;
1084
1085 offset = (unsigned int)(bio->bi_sector & dmc->block_mask);
1086 request_block = bio->bi_sector - offset;
1087
1095 cache_insert(dmc, request_block, cache_block); /* Update metadata first */
1096
1097 job = new_kcached_job(dmc, bio, request_block, cache_block);
1098
1099 head = to_bytes(offset);
1100
1101 left = (dmc->src_dev->bdev->bd_inode->i_size>>9) - request_block;
1102 if (left < dmc->block_size) {
1103 tail = to_bytes(left) - bio->bi_size - head;
1104 job->src.count = left;
1105 job->dest.count = left;
1106 } else
1107 tail = to_bytes(dmc->block_size) - bio->bi_size - head;
1108
1109 /* Requested block is aligned with a cache block */
1110 if (0 == head && 0 == tail)
1111 job->nr_pages= 0;
1112 else /* Need new pages to store extra data */
1113 job->nr_pages = dm_div_up(head, PAGE_SIZE) + dm_div_up(tail, PAGE_SIZE);
1114 job->rw = READ; /* Fetch data from the source device */
1115
1118 queue_job(job);
1119
1120 return 0;
1121 }
函数首先调用cache_insert()更新cache, 设置该cacheblock.state为RESERVED. 然后调用new_kcached_job()分配一个kcached_job对象. 第1109~1104行是核心代码, 如前文所述, 上层请求的bio已经由DM框架按cacheblock单位切分, 也就是说, cache_map()所处理的每个bio请求的扇区数最大为cacheblock. 如下图所示: 第1099行获得这个bio在cacheblock中的偏移, 保存在head. 第1101行获得第request_block块扇区到磁盘最后一块扇区所跨过的扇区数. 第1103或1107行获得bio请求的数据最后一个字节离磁盘最后一字节(或者下一个cacheblock)的偏移. 第1110行, 如果0 == head且0 == tail, 说明所请求的bio正好覆盖整个cacheblock. 否则, 说明请求的bio只占cacheblock的一部分, 针对这种情况, 需要为该bio未请求的前后两部分分别分配页面. 因为dm-cache请求磁盘的单位为cacheblock大小. 第1114行指定job的读写方向为READ. 最后, 第1118行提交job.
回头看看cache_read_miss()中的1097行分配job所调用的函数new_kcached_job(), 第3个参数request_block表示bio请求在磁盘的起始扇区号, 第4个参数cache_block表示bio请求在SSD的起始扇区号.
1049 static struct kcached_job *new_kcached_job(struct cache_c *dmc, struct bio* bio,
1050 sector_t request_block,
1051 sector_t cache_block)
1052 {
1053 struct dm_io_region src, dest;
1054 struct kcached_job *job;
1055
1056 src.bdev = dmc->src_dev->bdev;
1057 src.sector = request_block;
1058 src.count = dmc->block_size;
1059 dest.bdev = dmc->cache_dev->bdev;
1060 dest.sector = cache_block << dmc->block_shift;
1061 dest.count = src.count;
1062
1063 job = mempool_alloc(_job_pool, GFP_NOIO);
1064 job->dmc = dmc;
1065 job->bio = bio;
1066 job->src = src;
1067 job->dest = dest;
1068 job->cacheblock = &dmc->cache[cache_block];
1069
1070 return job;
1071 }
接下来看看job结构的定义:
126 /* Structure for a kcached job */
127 struct kcached_job {
128 struct list_head list;
129 struct cache_c *dmc;
130 struct bio *bio; /* Original bio */
131 struct dm_io_region src;
132 struct dm_io_region dest;
133 struct cacheblock *cacheblock;
134 int rw;
135 /*
136 * When the original bio is not aligned with cache blocks,
137 * we need extra bvecs and pages for padding.
138 */
139 struct bio_vec *bvec;
140 unsigned int nr_pages;
141 struct page_list *pages;
142 };
在dm-cache中, job有3种状态, 它以list字段链入其所属于的链表, 分别为_io_jobs, _pages_jobs和_complete_jobs. 其中, io_jobs表示待执行IO的任务, page_jobs待分配页面的任务, compelet_jobs表示待收尾的任务. kcached_job的bio字段存储DM框架发给cache_map()的bio请求, src和dest分别指向磁盘和SSD的dm_io_region. cacheblock指针指向cache_c.cache数组中以请求的bio所落在的SSD磁盘上的cacheblock编号为下标的偏移. rw字段表示job当前的读写方向.
回到cache_read_miss()函数, 它在第1118行调用queue_job()提交了任务, 代码如下:
736 static void queue_job(struct kcached_job *job)
737 {
738 atomic_inc(&job->dmc->nr_jobs);
739 if (job->nr_pages > 0) /* Request pages */
740 push(&_pages_jobs, job);
741 else /* Go ahead to do I/O */
742 push(&_io_jobs, job);
743 wake();
744 }
可以看到, 如果需要为job分配页面, 则将job链入_pages_jobs链表, 否则, 链入_io_jobs链表. 然后调用wake():
299 static inline void wake(void)
300 {
301 queue_work(_kcached_wq, &_kcached_work);
302 }
wake()函数只是对queue_work()的封装, 它将_kcached_work提交到_kcached_wq. 在dm-cache模块初始化函数dm_cache_init()中, _kcached_work被注册的回调为do_work. 所以, 当_kcached_work被调度时, do_work()将被回调.
729 static void do_work(struct work_struct *ignored)
730 {
731 process_jobs(&_complete_jobs, do_complete);
732 process_jobs(&_pages_jobs, do_pages);
733 process_jobs(&_io_jobs, do_io);
734 }
可见, do_work()依次遍历_complete_jobs, _pages_jobs和_io_jobs链表中的任务, 以任务为参数, 分别回调do_complete, do_pages, do_io. 在这里, 遍历的顺序是有讲究的: 先处理_complete_jobs任务, 是因为此类任务完成后可能释放一些页面回页面内存池; 然后处理_pages_jobs任务, 因为此类任务只有获取页面后才能执行IO操作, 它从页面内存池中获取页面; 最后处理_io_jobs链表任务.
process_jobs()代码如下:
696 /*
697 * Run through a list for as long as possible. Returns the count
698 * of successful jobs.
699 */
700 static int process_jobs(struct list_head *jobs,
701 int (*fn) (struct kcached_job *))
702 {
703 struct kcached_job *job;
704 int r, count = 0;
705
706 while ((job = pop(jobs))) {
707 r = fn(job);
708
709 if (r < 0) {
710 /* error this rogue job */
711 DMERR("process_jobs: Job processing error");
712 }
713
714 if (r > 0) {
715 /*
716 * We couldn't service this job ATM, so
717 * push this job back onto the list.
718 */
719 push(jobs, job);
720 break;
721 }
722
723 count++;
724 }
725
726 return count;
727 }
它依次遍历链表, 调用回调.
回到queue_job(), 前面说过, 因为dm-cache读写SSD及磁盘的粒度为cacheblock大小, 所以如果bio请求未对其cacheblock, 或请求大小不等于cacheblock大小, 则需要为该cacheblock中, bio不关心的前后部分分配页面, 即把job提交到_pages_jobs链表. 否则, 直接提交到_io_jobs链表.
_pages_jobs链表的回调函数do_pages非常简单, 它从页面内存池获取一些页面(页面数为nr_pages), 保存在kcached_job结构的pages字段, 然后将job提交到_io_jobs链表.
针对_io_jobs链表上的任务, do_work()将以do_io回调来处理该任务.
618 static int do_io(struct kcached_job *job)
619 {
620 int r = 0;
621
622 if (job->rw == READ) { /* Read from source device */
623 r = do_fetch(job);
624 } else { /* Write to cache device */
625 r = do_store(job);
626 }
627
628 return r;
629 }
针对读请求, 很明显是进入do_fetch()分支.
400 /*
401 * Fetch data from the source device asynchronously.
402 * For a READ bio, if a cache block is larger than the requested data, then
403 * additional data are prefetched. Larger cache block size enables more
404 * aggressive read prefetching, which is useful for read-mostly usage.
405 * For a WRITE bio, if a cache block is larger than the requested data, the
406 * entire block needs to be fetched, and larger block size incurs more overhead.
407 * In scenaros where writes are frequent, 4KB is a good cache block size.
408 */
409 static int do_fetch(struct kcached_job *job)
410 {
411 int r = 0, i, j;
412 struct bio *bio = job->bio;
413 struct cache_c *dmc = job->dmc;
414 unsigned int offset, head, tail, remaining, nr_vecs, idx = 0;
415 struct bio_vec *bvec;
416 struct page_list *pl;
417 printk("do_fetch");
418 offset = (unsigned int) (bio->bi_sector & dmc->block_mask);
419 head = to_bytes(offset);
420 tail = to_bytes(dmc->block_size) - bio->bi_size - head;
425
426 if (bio_data_dir(bio) == READ) { /* The original request is a READ */
427 if (0 == job->nr_pages) { /* The request is aligned to cache block */
428 r = dm_io_async_bvec(1, &job->src, READ,
429 bio->bi_io_vec + bio->bi_idx,
430 io_callback, job);
431 return r;
432 }
433
434 nr_vecs = bio->bi_vcnt - bio->bi_idx + job->nr_pages;
435 bvec = kmalloc(nr_vecs * sizeof(*bvec), GFP_NOIO);
436 if (!bvec) {
437 DMERR("do_fetch: No memory");
438 return 1;
439 }
440
441 pl = job->pages;
442 i = 0;
443 while (head) {
444 bvec[i].bv_len = min(head, (unsigned int)PAGE_SIZE);
445 bvec[i].bv_offset = 0;
446 bvec[i].bv_page = pl->page;
447 head -= bvec[i].bv_len;
448 pl = pl->next;
449 i++;
450 }
451
452 remaining = bio->bi_size;
453 j = bio->bi_idx;
454 while (remaining) {
455 bvec[i] = bio->bi_io_vec[j];
456 remaining -= bvec[i].bv_len;
457 i++; j++;
458 }
459
460 while (tail) {
461 bvec[i].bv_len = min(tail, (unsigned int)PAGE_SIZE);
462 bvec[i].bv_offset = 0;
463 bvec[i].bv_page = pl->page;
464 tail -= bvec[i].bv_len;
465 pl = pl->next;
466 i++;
467 }
468
469 job->bvec = bvec;
470 r = dm_io_async_bvec(1, &job->src, READ, job->bvec, io_callback, job);
471 return r;
472 } else { /* The original request is a WRITE */
541 }
542 }
-如果任务没有申请页面, 即bio请求正好cacheblock对齐且请求大小正好为一个cacheblock, 则直接调用dm_io_async_bvec().
-如果任务申请了页面, 即bio请求不是cacheblock对齐, 或者请求大小不是一个cacheblock, 则通过第434~467行代码主动构造一个bio_vec *bvec, 保存在job->bvec中, 然后调用dm_io_async_bvec().
仔细比较上述两种情况调用dm_io_async_bvec()所传递的参数, 不难发现, 只有第4个参数是不一样的. 前者传递的为原来请求的bio的bvec, 后者传递的为主动构造的bvec.
dm_io_async_bvec()函数提交IO, 从磁盘(job->src)中读取数据到第4个参数, 然后回调io_callback().
382 static void io_callback(unsigned long error, void *context)
383 {
384 struct kcached_job *job = (struct kcached_job *) context;
385
386 if (error) {
387 /* TODO */
388 DMERR("io_callback: io error");
389 return;
390 }
391
392 if (job->rw == READ) {
393 job->rw = WRITE;
394 push(&_io_jobs, job);
395 } else
396 push(&_complete_jobs, job);
397 wake();
398 }
读请求的job->rw为READ, 将其修改为WRITE后将job提交到_io_jobs链表. _io_jobs链表元素再次由do_work()以do_io()回调. 此时, 因为job->rw为WRITE, 所以调用的函数变成了do_store().
544 /*
545 * Store data to the cache source device asynchronously.
546 * For a READ bio request, the data fetched from the source device are returned
547 * to kernel and stored in cache at the same time.
548 * For a WRITE bio request, the data are written to the cache and source device
549 * at the same time.
550 */
551 static int do_store(struct kcached_job *job)
552 {
553 int i, j, r = 0;
554 struct bio *bio = job->bio ;
555 struct cache_c *dmc = job->dmc;
556 unsigned int offset, head, tail, remaining, nr_vecs;
557 struct bio_vec *bvec;
558 offset = (unsigned int) (bio->bi_sector & dmc->block_mask);
559 head = to_bytes(offset);
560 tail = to_bytes(dmc->block_size) - bio->bi_size - head;
566
567 if (0 == job->nr_pages) /* Original request is aligned with cache blocks */
568 r = dm_io_async_bvec(1, &job->dest, WRITE, bio->bi_io_vec + bio->bi_idx,
569 io_callback, job);
570 else {
571 if (bio_data_dir(bio) == WRITE && head > 0 && tail > 0) {
573 nr_vecs = job->nr_pages + bio->bi_vcnt - bio->bi_idx;
574 if (offset && (offset + bio->bi_size < PAGE_SIZE)) nr_vecs++;
576 bvec = kmalloc(nr_vecs * sizeof(*bvec), GFP_KERNEL);
577 if (!bvec) {
578 DMERR("do_store: No memory");
579 return 1;
580 }
581
582 i = 0;
583 while (head) {
584 bvec[i].bv_len = min(head, job->bvec[i].bv_len);
585 bvec[i].bv_offset = 0;
586 bvec[i].bv_page = job->bvec[i].bv_page;
587 head -= bvec[i].bv_len;
588 i++;
589 }
590 remaining = bio->bi_size;
591 j = bio->bi_idx;
592 while (remaining) {
593 bvec[i] = bio->bi_io_vec[j];
594 remaining -= bvec[i].bv_len;
595 i++; j++;
596 }
597 j = (to_bytes(offset) + bio->bi_size) / PAGE_SIZE;
598 bvec[i].bv_offset = (to_bytes(offset) + bio->bi_size) -
599 j * PAGE_SIZE;
600 bvec[i].bv_len = PAGE_SIZE - bvec[i].bv_offset;
601 bvec[i].bv_page = job->bvec[j].bv_page;
602 tail -= bvec[i].bv_len;
603 i++; j++;
604 while (tail) {
605 bvec[i] = job->bvec[j];
606 tail -= bvec[i].bv_len;
607 i++; j++;
608 }
609 kfree(job->bvec);
610 job->bvec = bvec;
611 }
612
613 r = dm_io_async_bvec(1, &job->dest, WRITE, job->bvec, io_callback, job);
614 }
615 return r;
616 }
这段代码和do_fetch()非常相像, 不再细述. 它把do_fetch()中从磁盘读取的数据, 通过dm_io_async_bvec()函数, 写入SSD(job->dest). 然后io_callback()再次被回调. 此时, 因为job->rw为WRITE, io_callback()将任务提交到_complete_jobs链表. 该链表对应的回调函数为do_complete():
673 static int do_complete(struct kcached_job *job)
674 {
675 int r = 0;
676 struct bio *bio = job->bio;
677
680 bio_endio(bio, 0);
681
682 if (job->nr_pages > 0) {
683 kfree(job->bvec);
684 kcached_put_pages(job->dmc, job->pages);
685 }
686
687 flush_bios(job->cacheblock);
688 mempool_free(job, _job_pool);
689
690 if (atomic_dec_and_test(&job->dmc->nr_jobs))
691 wake_up(&job->dmc->destroyq);
692
693 return r;
694 }
do_complete()首先调用bio_endio(), 告诉IO子系统上层, 当前bio已经处理完成. 然后释放页面. 之后调用flush_bios()重新提交在当前bio之后所有发往同个cacheblock的bios, 最后释放job.
至此, 读请求完成. 写请求与读请求大同小异, 不表.
总结陈词
IO处理内核化是一种有效的IO优化方式. 另外, IO路径网络化(iSCSI)也是大势所趋, 如Amazon的EBS及腾讯的CBS(入门参考块存储的世界). 希望以后一窥究竟.
谢谢你的分享,通过阅读dm-cache的文章,才真正理清楚flashcache的代码结构,真的很感谢~
Thanks!非常感谢您的慷慨分享。
写得真心很好,思路清晰,没有废话,全说到点上了。