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

发表于 | 更新于 | 分类于 | 热度：
本文字数： 3.2k | 阅读时长 ≈ 3 分钟

前言

本文记录了在使用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%