当DirectIO遇到Loop设备
前言
本文记录了在使用DirectIO对Loop设备与真实设备进行吞吐量对比测试时，遇到的异常情况。通过该异常情况，分析了Loop设备的工作原理。
Loop设备
/dev/loop设备在Linux中是一种伪设备，这种设备可以让文件如同块设备一般被访问，让普通文件可以像块设备被格式化文件系统，可以进行挂载。Loop设备必须与一个现有的文件进行关联，如果文件中包含文件系统，那么这个文件就可以被挂载。例如，查看当前系统空闲的Loop设备：
losetup -f
关联空闲设备loop1到一个现有文件test.img，格式化为ext4文件系统并挂载到./mnt目录下。
losetup /dev/loop1 test.img
mount /dev/loop1 ./mnt/
mkfs.ext4 /dev/loop1
DirectIO
直接IO是一种无缓冲的IO，对文件的读写操作不会经过操作系统内核中的文件缓存。内核文件缓存中提供的预读取、延迟写入等机制不一定适合所有应用场景，例如数据库通常有一套自身的缓存机制和落盘机制，如果没有能够绕过内核文件缓存的机制，就会存在双重缓存。DirectIO就提供了绕过内核文件缓存的方法。
在open文件的时候设置 O_DIRECT 标识就可以使用DirectIO。
fd = open(argv[1], O_RDONLY | O_DIRECT);
DirectIO吞吐量对比
分别对真实设备和Loop设备进行吞吐量测试。实验猜想：真实设备的吞吐量会明显高于Loop设备。因为采用DirectIO都绕过内核缓存去设备中读取数据的情况下，Loop设备因为是关联的一个已存在的文件，会转化为对原镜像文件test.img的读取，在经过两层IO栈的情况下，吞吐量会低于直接读取真实设备。
吞吐量测试程序如下：
fd = open(argv[1], O_RDONLY | O_DIRECT);
if (fd == -1)
printf("open\n");
gettimeofday(&start, NULL);
while (numRead != 0) {
numRead = read(fd, buf, size);
totalnumRead += numRead;
if (numRead == -1) {
printf("Error\n");
return 0;
}
}
gettimeofday(&end, NULL);
double elapsed_time = ((double)t)/CLOCKS_PER_SEC;
secs_used=(end.tv_sec - start.tv_sec);
micros_used = secs_used*1000000 + end.tv_usec - start.tv_usec;
printf("Throughput = %f\n", (double)totalnumRead/micros_used);
使用该程序分别读取Loop设备中的文件./mnt/loop_file，真实设备中的文件./device_file。
真实设备吞吐量如下图所示，在120左右：
Loop设备吞吐量如下图所示，在700左右：
实验结果与猜想正好相反，Loop设备的吞吐量远大于真实设备。是什么原因造成了这种结果呢？
实验现象分析
Loop设备的吞吐量如此高，猜想它在设置O_DIRECT标识的情况下，还是使用了内核中的文件缓存，才会比真实设备快。通过如下两步进行验证：
-
查看测试程序执行前后，系统中cache大小的变化情况。
-
通过trace工具根据内核中函数调用栈，判断测试程序是走的buff IO分支还是direct IO分支。
cache大小分析
首先清空系统中的文件cache，清空后的buff/cache大小为213816KB。
#!/bin/bash
free
sync; sudo echo 3 > /proc/sys/vm/drop_caches
free
执行Loop设备下的吞吐量测试程序，可以看到清空缓存后，第一次执行，吞吐量变低了，后续执行结果，又回到了高吞吐量。说明后续读取内容都命中了缓存，吞吐量变高。
继续查看现在系统中的cache大小，变成了267688KB，增加了50M的大小。而我们读写的文件大小为40M，也很接近。
所以，在设置O_DIRECT标识的情况下对Loop设备中的文件进行读取，Loop设备还是使用了内核中的文件缓存。那么Loop设备具体是在哪里使用了缓存呢？
Loop设备读操作内核栈跟踪
猜想Loop设备的调用栈如下图所示，在这个调用栈里面如果Loop设备使用缓存，最可能就是在下图中两个橙色的文件缓存处。接下来我们对这个假设进行验证。
我们需要捕获到读取loop设备中文件的内核调用栈，才能验证上图是正确的。上图中经过了两次ext4文件系统，所以我们先跟踪一下ext4_file_read_iter函数，看一次read是否调用了两次该函数。
借助bcc，成功捕获到了两次ext4读取操作。如下图所示，第一次由read发起，第二次由loop1发起，而且第二次执行是由内核线程kthread执行的kthread work，很明显loop_queue_work是loop驱动设置的work回调函数。
loop_queue_work由loop设备驱动初始化时设置的多请求队列函数操作集中的loop_init_request函数设置，过程如下图所示。当块层的请求队列进行请求派发时，就会唤醒worker，执行该函数。（/drivers/block/loop.c）
下面我们需要跟踪执行loop_queue_work的函数调用栈，查看第一段读操作的IO栈完整路径。这次我们挂载loop驱动中负责处理块层多请求队列派发的request函数，即上图中的loop_queue_rq，调用栈如下图所示（自下向上）。
可以看到第一段IO栈由于设置了O_DIRECT标识的原因，确实没有使用内核文件缓存，执行了ext4_direct_IO分支。
块层一些函数的主要功能如下：
blk_finish_plug : IO请求泄流(进程)
blk_flush_plug_list ： 发起泄流
blk_mq_flush_plug_list ： 多请求队列泄流
blk_mq_sched_insert_requests ： 如果定义了调度算法则插入调度器。
blk_mq_run_hw_queue ： 启动硬件队列，派发request到块设备驱动
__blk_mq_delay_run_hw_queue ：派发hctx->dispatch链表
blk_mq_sched_dispatch_requests ： 执行各种派发（直接派发、软件队列派发、调度队列派发）
blk_mq_do_dispatch_sched ： 派发调度器的请求队列
loop_queue_rq ：即queue_rq，是一个钩子函数，由具体的设备驱动定义用来处理request，loop_queue_rq是loop设备定义的处理函数，在驱动初始化时注入。
loop_queue_rq最终会将work插入到worker队列中，并唤醒睡眠的 worker->task，此刻 worker 上 work 的 work->func 得以执行，此处就是执行loop_queue_work。
loop驱动如何处理请求
从下图loop1发起的第二次IO调用栈可以看到，loop驱动又将请求转发到了虚拟文件系统层，即函数vfs_iter_read。此时就是对loop设备所关联的镜像文件进行IO操作了。接下来我们验证一下，第二段IO操作是否使用了文件缓存。
我们挑选缓存读中的负责预读窗口初始化的函数ondemand_readahead进行跟踪，结果如下图所示。结果显示了generic_file_buffered_read函数，第二段对镜像文件test.img的读取采用了buff IO。
至此，已经能够解释为什么在设置了O_DIRECT标识的情况下，loop设备的吞吐量比真实设备高那么多。loop设备在驱动层又将请求转发到了vfs层，进行对其关联镜像文件的第二段读取，在第二段读取的时候依然采用了buff IO。
读取loop设备的整体IO栈如下图所示。
后续工作
接下来分析一下，为什么第二段IO不能延续第一段IO的O_DIRECT标识。从loop_queue_work函数开始看loop驱动如何将第一次的请求转化为第二次的请求。
loop_queue_work
loop_handle_cmd
do_req_filebacked
do_req_filebacked函数中对读写和不同的读写类型进行了处理，direct IO是通过非阻塞I/O来进行io的转发。可以看出，loop设备关联的镜像文件是单独进行读写方式设置的，与第一段IO读写的方式是不相干的。那么cmd->use_aio是在何时进行设置的？
static int do_req_filebacked(struct loop_device *lo, struct request *rq)
{
struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset;
switch (req_op(rq)) {//跟据request的flag对文件进行不同的操作
case REQ_OP_FLUSH://flush操作
return lo_req_flush(lo, rq);
case REQ_OP_WRITE_ZEROES://discard操作
return lo_fallocate(lo, rq, pos,
(rq->cmd_flags & REQ_NOUNMAP) ?
FALLOC_FL_ZERO_RANGE :
FALLOC_FL_PUNCH_HOLE);
case REQ_OP_DISCARD://discard操作
return lo_fallocate(lo, rq, pos, FALLOC_FL_PUNCH_HOLE);
case REQ_OP_WRITE://写操作
if (lo->transfer)//配置了加密算法
return lo_write_transfer(lo, rq, pos);
else if (cmd->use_aio)//关联的镜像文件设置了direct I/O
return lo_rw_aio(lo, cmd, pos, WRITE);
else//buff IO
return lo_write_simple(lo, rq, pos);
case REQ_OP_READ://读操作
if (lo->transfer)
return lo_read_transfer(lo, rq, pos);
else if (cmd->use_aio)//关联的镜像文件设置了direct I/O
return lo_rw_aio(lo, cmd, pos, READ);
else//buff IO
return lo_read_simple(lo, rq, pos);
default:
WARN_ON_ONCE(1);
return -EIO;
break;
}
}
从man手册中loop下面可以看到，可以通过ioctl来设置backing file为direct IO模式。 
查看loop驱动中的ioctl处理函数，loop_set_dio函数对该ioctl命令进行处理。
//drivers/block/loop.c
static int lo_ioctl(struct block_device *bdev, fmode_t mode,
unsigned int cmd, unsigned long arg)
{
struct loop_device *lo = bdev->bd_disk->private_data;
int err;
mutex_lock_nested(&lo->lo_ctl_mutex, 1);
switch (cmd) {
case LOOP_SET_FD:
err = loop_set_fd(lo, mode, bdev, arg);
break;
......
case LOOP_SET_DIRECT_IO://处理direct IO设置
err = -EPERM;
if ((mode & FMODE_WRITE) || capable(CAP_SYS_ADMIN))
err = loop_set_dio(lo, arg);
break;
.......
}
}
__loop_update_dio会对lo->use_dio进行判断和配置。
static int loop_set_dio(struct loop_device *lo, unsigned long arg)
{
int error = -ENXIO;
if (lo->lo_state != Lo_bound)
goto out;
__loop_update_dio(lo, !!arg);
if (lo->use_dio == !!arg)
return 0;
error = -EINVAL;
out:
return error;
}
但是我们在驱动处理请求时判断diretIO是使用的cmd->use_aio，这个变量是何时和lo->use_dio关联起来的呢？
static blk_status_t loop_queue_rq(struct blk_mq_hw_ctx *hctx,
const struct blk_mq_queue_data *bd)
{
switch (req_op(cmd->rq)) {
case REQ_OP_FLUSH:
case REQ_OP_DISCARD:
case REQ_OP_WRITE_ZEROES:
cmd->use_aio = false;
break;
default://设置backing file的读写方式
cmd->use_aio = lo->use_dio;
break;
}
kthread_queue_work(&lo->worker, &cmd->work);
return BLK_STS_OK;
}
loop_queue_rq中对cmd->use_aio进行了赋值。最后，lo->use_dio的默认值在何时设置的？loop_set_fd函数负责将loop设备和某个文件进行关联，在其中初始化了lo->use_dio为false。
static int loop_set_fd(struct loop_device *lo, fmode_t mode,
struct block_device *bdev, unsigned int arg)
{
struct file *file;
struct inode *inode;
struct address_space *mapping;
int lo_flags = 0;
int error;
loff_t size;
......
lo->use_dio = false;//默认不采用directIO
lo->lo_device = bdev;
lo->lo_flags = lo_flags;
lo->lo_backing_file = file;
lo->transfer = NULL;
lo->ioctl = NULL;
lo->lo_sizelimit = 0;
......
return error;
}
总结
至此，我们已经弄清了为什么loop设备在direct IO读写设置下，还是能够使用内核文件缓存。总结如下：
-
loop设备关联的backing file ，其读写方式需要单独进行设置。
-
loop设备关联文件的读写方式默认为buff IO。
-
系统通过ioctl系统调用，设置backing file的读写方式，对应的cmd为LOOP_SET_DIRECT_IO。
期待与你共同成长
微信号：知书码迹
更多精彩内容：http://szp2016.github.io/
- Linux 考古笔记
- Linux新技术基石 |eBPF and XDP
- 今晚直播-基于eBPF的Linux显微镜（LMP）产学研子项目分享 - 第二场
- eBPF Verifier内存越界实例分析
- 金秋十月首届中国eBPF研讨会将在西安举办
- 今晚八点直播：基于eBPF的CPU子系统指标提取与准确性分析
- 一位小白踏入Linux内核补丁提交大门的真实体验
- 简说 套接字缓存的内存空间布局
- 从read开始分析系统调用的上下文切换
- 今晚8点直播 - 闪存友好型文件系统的基础与优化
- 通过性能指标学习Linux Kernel - （下）
- Linux下用户程序的data段和bss段
- Linux CFS调度算法-虚拟时间
- 系统调用角度看用户栈与内核栈切换
- 当DirectIO遇到Loop设备
- Linux内核基础-进程用户栈与内核栈
- Linux内核网络收包角度—浅入中断(2)
- 揭秘 BPF map 前生今世
- 高温预警 今晚8点 eBPF工作原理浅析 边听边练
- Linux内核网络收包角度——浅入中断(1)