谷动谷力

 找回密码
 立即注册
查看: 504|回复: 0
收起左侧

Linux文件读写(BIO)波澜壮阔的一生

[复制链接]
发表于 2023-11-5 22:42:30 | 显示全部楼层 |阅读模式
Linux文件读写(BIO)波澜壮阔的一生


前言

网上关于BIO和块设备读写流程的文章何止千万,但是能够让你彻底读懂读明白的文章实在难找,可以说是越读越糊涂!
我曾经跨过山和大海 也穿过人山人海
我曾经问遍整个世界 从来没得到答案

本文用一个最简单的read(fd, buf, 4096)的代码,分析它从开始读到读结束,在整个Linux系统里面波澜壮阔的一生。本文涉及到的代码如下:
  1. #include <unistd.h>

  2. #include <fcntl.h>



  3. main()

  4. {

  5.         int fd;

  6.         char buf[4096];

  7.    

  8.         sleep(30); //run ./funtion.sh to trace vfs_read of this process

  9.         fd = open("file", O_RDONLY);

  10.         read(fd, buf, 4096);

  11.         read(fd, buf, 4096);

  12. }
复制代码


Page cache与预读

在Linux中,内存充当硬盘的page cache,所以,每次读的时候,会先check你读的那一部分硬盘文件数据是否在内存命中,如果没有命中,才会去硬盘;如果已经命中了,就直接从内存里面读出来。如果是写的话,应用如果是以非SYNC方式写的话,写的数据也只是进内存,然后由内核帮忙在适当的时机writeback进硬盘。
640?wx_fmt=png.jpg
代码中有2行read(fd, buf, 4096),第1行read(fd, buf, 4096)发生的时候,显然”file”文件中的数据都不在内存,这个时候,要执行真正的硬盘读,app只想读4096个字节(一页),但是内核不会只是读一页,而是要多读,提前读,把用户现在不读的也先读,因为内核怀疑你读了一页,接着要连续读,怀疑你想读后面的。与其等你发指令,不如提前先斩后奏(存储介质执行大块读比多个小块读要快),这个时候,它会执行预读,直接比如读4页,这样当你后面接着读第2-4页的硬盘数据的时候,其实是直接命中了。
所以这个代码路径现在是 :
640?wx_fmt=png.jpg
当你执行完第一个read(fd, buf, 4096)后,”file”文件的0~16KB都进入了pagecache,同时内核会给第2页标识一个PageReadahead标记,意思就是如果app接着读第2页,就可以预判app在做顺序读,这样我们在app读第2页的时候,内核可以进一步异步预读。
第一个read(fd,buf, 4096)之前,page cache命中情况(都不命中):
640?wx_fmt=png.jpg
第一个read(fd,buf, 4096)之后,page cache命中情况:
640?wx_fmt=png.jpg
我们紧接着又碰到第二个read(fd, buf, 4096),它要读硬盘文件的第2页内容,这个时候,第2页是page cache命中的,这一次的读,由于第2页有PageReadahead标记,让内核觉得app就是在顺序读文件,内核会执行更加激进的异步预读,比如读文件的第16KB~48KB。
所以第二个read(fd,buf, 4096)的代码路径现在是 :
640?wx_fmt=png.jpg
第二个read(fd,buf, 4096)之前,page cache命中情况:
640?wx_fmt=png.jpg
第二个read(fd,buf, 4096)之后,page cache命中情况:
640?wx_fmt=png.jpg
内存到硬盘的转换

刚才我们提到,第一次的read(fd, buf, 4096),变成了读硬盘里面的16KB数据,到内存的4个页面(对应硬盘里面文件数据的第0~16KB)。但是我们还是不知道,硬盘里面文件数据的第0~16KB在硬盘的哪些位置?我们必须把内存的页,转化为硬盘里面真实要读的位置。
在Linux里面,用于描述硬盘里面要真实操作的位置与page cache的页映射关系的数据结构是bio。相信大家已经见到bio一万次了,但是就是和真实的案例对不上。
bio的定义如下(include/linux/blk_types.h):
  1. struct bio_vec {

  2.        struct page    *bv_page;

  3.        unsigned int  bv_len;

  4.        unsigned int  bv_offset;

  5. };

  6. struct bio {

  7.        struct bio              *bi_next; /* request queue link */

  8.        struct block_device      *bi_bdev;

  9.        …

  10.        struct bvec_iter     bi_iter;



  11.        /* Number of segments in this BIO after

  12.         * physical address coalescing is performed.

  13.         */

  14.        unsigned int         bi_phys_segments;

  15.        …

  16.        bio_end_io_t         *bi_end_io;



  17.        void               *bi_private;



  18.        unsigned short            bi_vcnt;  /* how many bio_vec's */

  19.        atomic_t        bi_cnt;           /* pin count */

  20.        struct bio_vec       *bi_io_vec;     /* the actual vec list */

  21.        …

  22. };
复制代码

它是一个描述硬盘里面的位置与page cache的页对应关系的数据结构,每个bio对应的硬盘里面一块连续的位置,每一块硬盘里面连续的位置,可能对应着page cache的多页,或者一页,所以它里面会有一个bio_vec *bi_io_vec的表。
我们现在假设2种情况
第1种情况是page_cache_sync_readahead()要读的0~16KB数据,在硬盘里面正好是顺序排列的(是否顺序排列,要查文件系统,如ext3、ext4),Linux会为这一次4页的读,分配1个bio就足够了,并且让这个bio里面分配4个bi_io_vec,指向4个不同的内存页:
640?wx_fmt=png.jpg
第2种情况是page_cache_sync_readahead()要读的0~16KB数据,在硬盘里面正好是完全不连续的4块 (是否顺序排列,要查文件系统,如ext3、ext4),Linux会为这一次4页的读,分配4个bio,并且让这4个bio里面,每个分配1个bi_io_vec,指向4个不同的内存页面:
640?wx_fmt=png.jpg
当然你还可以有第3种情况,比如0~8KB在硬盘里面连续,8~16KB不连续,那可以是这样的:
640?wx_fmt=png.jpg
其他的情况请类似推理…完成这项工作的史诗级的代码就是mpage_readpages()。
640?wx_fmt=png.jpg
mpage_readpages()会间接调用ext4_get_block(),真的搞清楚0~16KB的数据,在硬盘里面的摆列位置,并依据这个信息,转化出来一个个的bio。
bio和request的三进三出

人生,说到最后,简单得只有生死两个字。但由于有了命运的浮沉,由于有了人世的冷暖,简单的过程才变得跌宕起伏,纷繁复杂。小平三落三起,最终建立了不朽的功勋。曼德拉受非人待遇在监狱服刑数十年,终成世界公认的领袖。走向自由之路不会平坦,斗争就是生活。与天斗,其乐无穷;与地斗,其乐无穷;与Linux斗,痛苦无穷!
bio产生后,到最终的完成,同样经历了三进三出的队列,这个过程的艰辛和痛苦,让人欲罢不能,欲说还休,求生不得求死不能。
这三步是:
1.原地蓄势
把bio转化为request,把request放入进程本地的plug队列;蓄势多个request后,再进行泄洪。
2.电梯排序
进程本地的plug队列的request进入到电梯,进行再次的合并、排序,执行QoS的排队,之后按照QoS的结果,分发给块设备驱动。电梯内部的实现,可以有各种各样的队列。
3.分发执行
电梯分发的request,被设备驱动的request_fn()挨个取出来,派发真正的硬件读写命令到硬盘。这个分发的队列,一般就是我们在块设备驱动里面见到的request_queue了。
640?wx_fmt=png.jpg
下面我们再一一呈现,这三进三出。
原地蓄势
在Linux中,每个task_struct(对应一个进程,或轻量级进程——线程),会有一个plug的list。什么叫plug呢?类似于葛洲坝和三峡,先蓄水,当app需要发多个bio请求的时候,比较好的办法是先蓄势,而不是一个个单独发给最终的硬盘。
这个类似你现在有10个老师,这10个老师开学的时候都接受学生报名。然后有一个大的学生队列,如果每个老师有一个学生报名的时候,都访问这个唯一的学生队列,那么这个队列的操作会变成一个重要的锁瓶颈:
640?wx_fmt=png.jpg
如果我们换一个方法,让每个老师有学生报名的时候,每天的报名的学生挂在老师自己的队列上面,老师的队列上面挂了很多学生后,一天之后再泄洪,挂到最终的学生队列,则可以避免这个问题,最终小队列融合进大队列的时候控制住时序就好。
640?wx_fmt=png.jpg

你会发现,代码路径是这样的:
640?wx_fmt=png.jpg
read_pages()函数先把闸门拉上,然后发起一系列bio后,再通过blk_finish_plug()的调用来泄洪。
640?wx_fmt=png.jpg
在这个蓄势的过程中,还要完成一项重要的工作,就是make request(造请求)。这个完成“造请求”的史诗级的函数,一般是void blk_queue_bio(struct request_queue *q, struct bio *bio),位于block/blk-core.c。
它会尝试把bio合并进入一个进程本地plug list里面的一个request,如果无法合并,则造一个新的request。request里面包含一个bio的list,这个list的bio对应的硬盘位置,最终在硬盘上是连续存放的。
下面我们假设"file"的第0~16KB在硬盘的存放位置为:
640?wx_fmt=png.jpg
根据我们前面"内存到硬盘的转换"一节举的例子,这属于在硬盘里面完全不连续的"情况2",于是这4块数据,会被史诗级的mpage_readpages()转化为4个bio。
640?wx_fmt=png.jpg
当他们进入进程本地的plug list的时候,由于最开始plug list为空,100显然无法与谁合并,这样形成一个新的request0。
Bio1也无法合并进request0,于是得到新的request1。
Bio2正好可以合并进request1,于是Bio1合并进request1。
Bio3对应硬盘的200块,无法合并,于是得到新的request2。
现在进程本地plug list上的request排列如下:
640?wx_fmt=png.jpg

泄洪的时候,进程本地的plug list的request,会通过调用elevator调度算法的elevator_add_req_fn() callback函数,被加入电梯的队列。
电梯排序
当各个进程本地的plug list里面的request被泄洪,以排山倒海之势进入的,不是最终的设备驱动(不会直接被拍死在沙滩上的),而是一个电梯排队算法,进行再一次的排队。这个电梯调度,其实目的3个:
  • 进一步的合并request
  • 把request对硬盘的访问变得顺序化
  • 执行QoS

电梯的内部实现可以非常灵活,但是入口是elevator_add_req_fn(),出口是elevator_dispatch_fn()。
640?wx_fmt=png.jpg
合并和排序都好理解,下面我们重点解释QoS(服务质量)。想象你家里的宽带,有迅雷,有在线电影,有机顶盒看电视。
当你只用迅雷下电影的时候,你当然可以全速的下电影,但是当你还看电视,在线看电影,这个时候,你可能会对迅雷限流,以保证相关电视盒电影的服务质量。
电梯调度里面也执行同样的逻辑,比如CFQ调度算法,可以根据进程的ionice,调整不同进程访问硬盘的时候的优先级。比如,如下2个优先级不同的dd
  1. # ionice-c 2 -n 0 cat /dev/sda > /dev/null&

  2. # ionice -c 2 -n 7 cat /dev/sda >/dev/null&
复制代码

最终访问硬盘的速度是不一样的,一个371M,一个只有72M。
640?wx_fmt=png.jpg
所以当泄洪开始,漫江碧透,百舸争流,谁能到中流击水,浪遏飞舟?QoS是一个关于一将功成万骨枯的故事。
目前常用的IO电梯调度算法有:cfq, noop, deadline。详细的区别不是本文的重点,建议阅读《刘正元\"\"inux 通用块层之DeadLine IO调度器》从了解deadline的实现开始。
分发执行
到了最后要交差的时刻了,设备驱动的request_fn()通过调用电梯调度算法的elevator_dispatch_fn()取出经过QoS排序后的request并发命令给最终的存储设备执行I/O动作。
  1. static void xxx_request_fn(struct request_queue *q)

  2. {

  3.         struct request *req;

  4.         struct bio *bio;



  5.         while ((req = blk_peek_request(q)) != NULL) {

  6.                 struct xxx_disk_dev *dev = req->rq_disk->private_data;

  7.                 if (req->cmd_type != REQ_TYPE_FS) {

  8.                         printk (KERN_NOTICE "Skip non-fs request\n");

  9.                         blk_start_request(req);

  10.                         __blk_end_request_all(req, -EIO);

  11.                         continue;

  12.                 }



  13.                 blk_start_request(req);

  14.                 __rq_for_each_bio(bio, req)

  15.                         xxx_xfer_bio(dev, bio);

  16.         }

  17. }
复制代码

request_fn()只是派发读写事件和命令,最终的完成一般是在另外一个上下文,而不是发起IO的进程。request处理完成后,探知到IO完成的上下文会以blk_end_request()的形式,通知等待IO请求完成的本进程。主动发起IO的进程的代码序列一般是:
  • submit_bio()
  • io_schedule(),放弃CPU。

blk_end_request()一般把io_schedule()后放弃CPU的进程唤醒。io_schedule()的这段等待时间,会计算到进程的iowait时间上,详见:《朱辉(茶水):Linux Kernel iowait 时间的代码原理》
用Ftrace抓所有流程

本文所涉及到的所有流程,都可以用ftrace跟踪到。这样可以了解更多更深刻的细节。
  1. char buf[4096];

  2.    

  3.         sleep(30); //run ./funtion.sh to trace vfs_read of this process

  4.         fd = open("file", O_RDONLY);

  5.         read(fd, buf, 4096);
复制代码

        
在上述代码的中间,我特意留下了30秒的延时,在这个延时的空挡,你可以启动如下的脚本,来对整个过程进行function graph的trace,抓取进程对vfs_read()开始后的调用栈:
  1. #!/bin/bash



  2. debugfs=/sys/kernel/debug

  3. echo nop > $debugfs/tracing/current_tracer

  4. echo 0 > $debugfs/tracing/tracing_on

  5. echo `pidof read` > $debugfs/tracing/set_ftrace_pid

  6. echo function_graph > $debugfs/tracing/current_tracer

  7. echo vfs_read > $debugfs/tracing/set_graph_function

  8. echo 1 > $debugfs/tracing/tracing_on
复制代码

笔者也是通过ftrace的结果,用vim打开,逐句分析的。关于ftrace使用的详细方法,可以阅读《宋宝华:关于Ftrace的一个完整案例》
640?wx_fmt=png.jpg
最后的话

本文描述的是主干,许多的细节和代码分支没有涉及,因为在本文描述太多的分支,会让读者抓不住主干。很多分支都没有介绍,比如unplug的泄洪,除了可以人为的blk_finish_plug()泄洪外,也会发生plug队列较满的时候,以及进程睡眠schedule()的时候的自动泄洪。另外,关于写,后面的三进三出的过程,基本与读类似,但是写有个page cache堆积和writeback的启动机制,是read所没有的。

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|深圳市光明谷科技有限公司|光明谷商城|Sunshine Silicon Corpporation ( 粤ICP备14060730号|Sitemap

GMT+8, 2024-2-28 18:26 , Processed in 0.117300 second(s), 37 queries .

Powered by Discuz! X3.2 Licensed

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表