linux内核源码阅读之facebook硬盘加速flashcache之四
这一小节介绍一下flashcache读写入口和读写的基础实现。首先,不管是模块还是程序,必须先找到入口,用户态代码会经常去先看main函数,内核看module_init,同样看IO流时候也要找到入口。flashcache作为一个dm_target,入口就是struct target_type 的map函数,对应的是flashcache_map函数:1581/*1582 * Decid
·
这一小节介绍一下flashcache读写入口和读写的基础实现。
首先,不管是模块还是程序,必须先找到入口,用户态代码会经常去先看main函数,内核看module_init,同样看IO流时候也要找到入口。flashcache作为一个dm_target,入口就是struct target_type 的map函数,对应的是flashcache_map函数:
1581/*
1582 * Decide the mapping and perform necessary cache operations for a bio request.
1583 */
1584int
1585flashcache_map(struct dm_target *ti, struct bio *bio,
1586 union map_info *map_context)
1587{
1588 struct cache_c *dmc = (struct cache_c *) ti->private;
1589 int sectors = to_sector(bio->bi_size);
1590 int queued;
1591
1592 if (sectors <= 32)
1593 size_hist[sectors]++;
1594
1595 if (bio_barrier(bio))
1596 return -EOPNOTSUPP;
1597
1598 VERIFY(to_sector(bio->bi_size) <= dmc->block_size);
1599
1600 if (bio_data_dir(bio) == READ)
1601 dmc->reads++;
1602 else
1603 dmc->writes++;
1604
1605 spin_lock_irq(&dmc->cache_spin_lock);
1606 if (unlikely(sysctl_pid_do_expiry &&
1607 (dmc->whitelist_head || dmc->blacklist_head)))
1608 flashcache_pid_expiry_all_locked(dmc);
1609 if ((to_sector(bio->bi_size) != dmc->block_size) ||
1610 (bio_data_dir(bio) == WRITE && flashcache_uncacheable(dmc))) {
1611 queued = flashcache_inval_blocks(dmc, bio);
1612 spin_unlock_irq(&dmc->cache_spin_lock);
1613 if (queued) {
1614 if (unlikely(queued < 0))
1615 flashcache_bio_endio(bio, -EIO);
1616 } else {
1617 /* Start uncached IO */
1618 flashcache_start_uncached_io(dmc, bio);
1619 }
1620 } else {
1621 spin_unlock_irq(&dmc->cache_spin_lock);
1622 if (bio_data_dir(bio) == READ)
1623 flashcache_read(dmc, bio);
1624 else
1625 flashcache_write(dmc, bio);
1626 }
1627 return DM_MAPIO_SUBMITTED;
1628}
第1588行,dmc = ti->private,是什么时候保持的这个指针呢?看构造函数flashcache_ctr
1350 ti->split_io = dmc->block_size;
1351 ti->private = dmc;
这里对private赋值,这里还有一个额外的收获,就是1350行,这是告诉dm层将IO分发为指定大小下发到dm_target设备。所以就有了flashcache_map函数1609行判断bio->bi_size是否为block_size大小。1606行和1610行是关于黑名单管理的,用于管理哪些进程或组不使用flashcache的,这里暂且不管,有兴趣可以查看flashcache_ioctl。
为什么大小不为block_size就直接下发到磁盘呢?因为flashcache只处理block_size大小的数据,由于设置了ti->spilit_io为block_size,所以flashcache_map接收到的数据都不会超过block_size,取大的bio在dm层被拆分成最大block_size的bio下发。那么处理小块数据对flashcache来讲有什么不好呢?因为flashcache为了提高效率都在按block_size下发到磁盘,这时有小的数据块缓存,那么必须要凑齐block_size才能下发,那怎么凑齐呢,就要去磁盘里读。所以flashcache对于缓存的数据是有选择性的,那么也决定了上层了流量模型不能是小块数据,这样的话flashcache就会直接下发到磁盘,就没起到缓存的作用了。
如果是小数据块的情况,第1611行调用flashcache_inval_block将与该bio有交集的cache块全部设置为INVALID,因为不再是最新的了。然后很不幸的是,设置cache块为invalid也会失败,按直观的想法就是设置一个脏标志位不就行了吗?根据墨菲定律,我们总是会过于乐观的判断一件事情。这里先不讲这些异常处理,因为如果还没有理解正常流程是什么样的,讲异常就失去了意义。
这样我们就很快找了正常流程的读写入口,第1623行是读入口,第1625行是写入口。
这里不急于去看读写实现,先来说说flashcache采用的读写磁盘的方法。
flashcache中跟磁盘相关的读写分为以下两类:
1)磁盘跟内存的交互
2)磁盘跟磁盘之前的交互
比如说读不命中时就是直接从磁盘读,属于第1种情况,那读命中呢?也是属于第1种情况,不过这时候是从SSD读。磁盘跟磁盘之间交互是用于写脏数据,将SSD中脏cache块拷贝到磁盘上去。现在介绍下两种情况使用的接口函数,这样后面在看读写流程时看到这两个函数就十分亲切了,并且清楚地知道数据是从哪里流向哪里。
首先看第一种情况是通过flashcache_dm_io_sync_vm函数实现的:
571int
572flashcache_dm_io_sync_vm(struct cache_c *dmc, struct dm_io_region *where, int rw, void *data)
573{
574 unsigned long error_bits = 0;
575 int error;
576 struct dm_io_request io_req = {
577 .bi_rw = rw,
578 .mem.type = DM_IO_VMA,
579 .mem.ptr.vma = data,
580 .mem.offset = 0,
581 .notify.fn = NULL,
582 .client = dmc->io_client,
583 };
584
585 error = dm_io(&io_req, 1, where, &error_bits);
586 if (error)
587 return error;
588 if (error_bits)
589 return error_bits;
590 return 0;
591}
这里我们只关心dm_io的使用,并不关心其实现,因为这已经涉及到dm层的代码了。
dmc 就是flashcache在内存中的管理结构
where是读写的目标设备
rw 读写
data 对应的内存地址
我们就以flashcache_md_create中读flash_superblock为例
720 header = (struct flash_superblock *)vmalloc(512);
721 if (!header) {
722 DMERR("flashcache_md_create: Unable to allocate sector");
723 return 1;
724 }
725 where.bdev = dmc->cache_dev->bdev;
726 where.sector = 0;
727 where.count = 1;
728#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)
729 error = flashcache_dm_io_sync_vm(&where, READ, header);
730#else
731 error = flashcache_dm_io_sync_vm(dmc, &where, READ, header);
732#endif
第一个参数dmc,第二个参数设置设备为SSD,即cache_dev->bdev,扇区0开始,1个扇区大小,读,目的地址是header。由于flashcache_dm_io_sync_vm中第581行设置fn=NULL,所以该函数是同步的。
现在看第二类磁盘和磁盘之间交互。看函数原型:
int dm_kcopyd_copy(struct dm_kcopyd_client *kc, struct dm_io_region *from,
unsigned num_dests, struct dm_io_region *dests,
unsigned flags, dm_kcopyd_notify_fn fn, void *context);
unsigned num_dests, struct dm_io_region *dests,
unsigned flags, dm_kcopyd_notify_fn fn, void *context);
第一个参数dm_kcopyd_client,在使用kcopyd异步拷贝服务时,必须先创建一个对应的client,创建在flashcache_ctr函数中
1208 r = dm_kcopyd_client_create(FLASHCACHE_COPY_PAGES, &dmc->kcp_client);
1209 if (r) {
1210 ti->error = "Failed to initialize kcopyd client\n";
1211 dm_io_client_destroy(dmc->io_client);
1212 goto bad3;
1213 }
第二个参数dm_io_region是源地址,第四个参数是目的地址,定义如下
struct dm_io_region {
struct block_device *bdev;
sector_t sector;
sector_t count; /* If this is zero the region is ignored. */
};
struct block_device *bdev;
sector_t sector;
sector_t count; /* If this is zero the region is ignored. */
};
dm_kcopyd_notify_fn fn是kcopyd处理完请求的回调函数
context 是回调函数参数,在flashcache都设置对应的kcached_job
小结一下,以上两类函数其实本质是一样的,调用者填写好源地址和目的地址,地址可以是内存中的也可以是设备的,填好之后就调用函数,再接着就等回调通知。就好比我们在网上购物,帐号(dm_client)登录,我们只负责填好订单(dm_io_region),具体的生产制造物流过程我不关心,我只关心门铃响(dm_kcopyd_notify_fn)的时候我要的物品都已经送上门来了。
更多推荐
已为社区贡献4条内容
所有评论(0)