基于DirectIO对Loop设备工作原理的分析

前言

本文记录了在使用DirectIO对Loop设备与真实设备进行吞吐量对比测试时,遇到的异常情况。通过该异常情况,分析了Loop设备的工作原理。

Loop设备

/dev/loop设备在Linux中是一种伪设备,这种设备可以让文件如同块设备一般被访问,让普通文件可以像块设备被格式化文件系统,可以进行挂载。
Loop设备必须与一个现有的文件进行关联,如果文件中包含文件系统,那么这个文件就可以被挂载。
例如,查看当前系统空闲的Loop设备:

losetup -f

关联空闲设备loop1到一个现有文件test.img,格式化为ext4文件系统并挂载到./mnt目录下。

1
2
3
4
5
losetup /dev/loop1 test.img

mount /dev/loop1 ./mnt/

mkfs.ext4 /dev/loop1

DirectIO

直接IO是一种无缓冲的IO,对文件的读写操作不会经过操作系统内核中的文件缓存。内核文件缓存中提供的预读取、延迟写入等机制不一定适合所有应用场景,例如数据库通常有一套自身的缓存机制和落盘机制,如果没有能够绕过内核文件缓存的机制,就会存在双重缓存。DirectIO就提供了绕过内核文件缓存的方法。

在open文件的时候设置 O_DIRECT 标识就可以使用DirectIO。

1
2

fd = open(argv[1], O_RDONLY | O_DIRECT);

DirectIO吞吐量对比

分别对真实设备和Loop设备进行吞吐量测试。
实验猜想:
真实设备的吞吐量会明显高于Loop设备。因为采用DirectIO都绕过内核缓存去设备中读取数据的情况下,Loop设备因为是关联的一个已存在的文件,会转化为对原镜像文件test.img的读取,在经过两层IO栈的情况下,吞吐量会低于直接读取真实设备。

吞吐量测试程序如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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标识的情况下,还是使用了内核中的文件缓存,才会比真实设备快。通过如下两步进行验证:

  1. 查看测试程序执行前后,系统中cache大小的变化情况。
  2. 通过trace工具根据内核中函数调用栈,判断测试程序是走的buff IO分支还是direct IO分支。

cache大小分析

首先清空系统中的文件cache,清空后的buff/cache大小为213816KB。

1
2
3
4
#!/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分支。

块层一些函数的主要功能如下:

1
2
3
4
5
6
7
8
9
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驱动如何将第一次的请求转化为第二次的请求。

1
2
3
loop_queue_work
loop_handle_cmd
do_req_filebacked

do_req_filebacked函数中对读写和不同的读写类型进行了处理,direct IO是通过非阻塞I/O来进行io的转发。可以看出,loop设备关联的镜像文件是单独进行读写方式设置的,与第一段IO读写的方式是不相干的。那么cmd->use_aio是在何时进行设置的?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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命令进行处理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
//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进行判断和配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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关联起来的呢?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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读写设置下,还是能够使用内核文件缓存。总结如下:

  1. loop设备关联的backing file ,其读写方式需要单独进行设置。
  2. loop设备关联文件的读写方式默认为buff IO。
  3. 系统通过ioctl系统调用,设置backing file的读写方式,对应的cmd为LOOP_SET_DIRECT_IO。
------ 本文结束------
0%