前言

本文记录了在使用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标识的情况下，还是使用了内核中的文件缓存，才会比真实设备快。通过如下两步进行验证：

1. 查看测试程序执行前后，系统中cache大小的变化情况。
2. 通过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读写设置下，还是能够使用内核文件缓存。总结如下：

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

本文由哈喽比特于2年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/73GvzDdtOsWpPXYEhAHmXw