趣谈Linux操作系统
刘超
网易杭州研究院云计算技术部首席架构师
立即订阅
19393 人已学习
课程目录
已完结 72 讲
0/4登录后,你可以任选4讲全文学习。
入门准备篇 (3讲)
开篇词 | 为什么要学习Linux操作系统?
免费
01 | 入学测验:你究竟对Linux操作系统了解多少?
02 | 学习路径:爬过这六个陡坡,你就能对Linux了如指掌
核心原理篇:第一部分 Linux操作系统综述 (3讲)
03 | 你可以把Linux内核当成一家软件外包公司的老板
04 | 快速上手几个Linux命令:每家公司都有自己的黑话
05 | 学会几个系统调用:咱们公司能接哪些类型的项目?
核心原理篇:第二部分 系统初始化 (4讲)
06 | x86架构:有了开放的架构,才能打造开放的营商环境
07 | 从BIOS到bootloader:创业伊始,有活儿老板自己上
08 | 内核初始化:生意做大了就得成立公司
09 | 系统调用:公司成立好了就要开始接项目
核心原理篇:第三部分 进程管理 (10讲)
10 | 进程:公司接这么多项目,如何管?
11 | 线程:如何让复杂的项目并行执行?
12 | 进程数据结构(上):项目多了就需要项目管理系统
13 | 进程数据结构(中):项目多了就需要项目管理系统
14 | 进程数据结构(下):项目多了就需要项目管理系统
15 | 调度(上):如何制定项目管理流程?
16 | 调度(中):主动调度是如何发生的?
17 | 调度(下):抢占式调度是如何发生的?
18 | 进程的创建:如何发起一个新项目?
19 | 线程的创建:如何执行一个新子项目?
核心原理篇:第四部分 内存管理 (7讲)
20 | 内存管理(上):为客户保密,规划进程内存空间布局
21 | 内存管理(下):为客户保密,项目组独享会议室封闭开发
22 | 进程空间管理:项目组还可以自行布置会议室
23 | 物理内存管理(上):会议室管理员如何分配会议室?
24 | 物理内存管理(下):会议室管理员如何分配会议室?
25 | 用户态内存映射:如何找到正确的会议室?
26 | 内核态内存映射:如何找到正确的会议室?
核心原理篇:第五部分 文件系统 (4讲)
27 | 文件系统:项目成果要归档,我们就需要档案库
28 | 硬盘文件系统:如何最合理地组织档案库的文档?
29 | 虚拟文件系统:文件多了就需要档案管理系统
30 | 文件缓存:常用文档应该放在触手可得的地方
核心原理篇:第六部分 输入输出系统 (5讲)
31 | 输入与输出:如何建立售前售后生态体系?
32 | 字符设备(上):如何建立直销模式?
33 | 字符设备(下):如何建立直销模式?
34 | 块设备(上):如何建立代理商销售模式?
35 | 块设备(下):如何建立代理商销售模式?
核心原理篇:第七部分 进程间通信 (7讲)
36 | 进程间通信:遇到大项目需要项目组之间的合作才行
37 | 信号(上):项目组A完成了,如何及时通知项目组B?
38 | 信号(下):项目组A完成了,如何及时通知项目组B?
39 | 管道:项目组A完成了,如何交接给项目组B?
40 | IPC(上):不同项目组之间抢资源,如何协调?
41 | IPC(中):不同项目组之间抢资源,如何协调?
42 | IPC(下):不同项目组之间抢资源,如何协调?
核心原理篇:第八部分 网络系统 (7讲)
43 预习 | Socket通信之网络协议基本原理
43 | Socket通信:遇上特大项目,要学会和其他公司合作
44 | Socket内核数据结构:如何成立特大项目合作部?
45 | 发送网络包(上):如何表达我们想让合作伙伴做什么?
46 | 发送网络包(下):如何表达我们想让合作伙伴做什么?
47 | 接收网络包(上):如何搞明白合作伙伴让我们做什么?
48 | 接收网络包(下):如何搞明白合作伙伴让我们做什么?
核心原理篇:第九部分 虚拟化 (7讲)
49 | 虚拟机:如何成立子公司,让公司变集团?
50 | 计算虚拟化之CPU(上):如何复用集团的人力资源?
51 | 计算虚拟化之CPU(下):如何复用集团的人力资源?
52 | 计算虚拟化之内存:如何建立独立的办公室?
53 | 存储虚拟化(上):如何建立自己保管的单独档案库?
54 | 存储虚拟化(下):如何建立自己保管的单独档案库?
55 | 网络虚拟化:如何成立独立的合作部?
核心原理篇:第十部分 容器化 (4讲)
56 | 容器:大公司为保持创新,鼓励内部创业
57 | Namespace技术:内部创业公司应该独立运营
58 | CGroup技术:内部创业公司应该独立核算成本
59 | 数据中心操作系统:上市敲钟
实战串讲篇 (9讲)
60 | 搭建操作系统实验环境(上):授人以鱼不如授人以渔
61 | 搭建操作系统实验环境(下):授人以鱼不如授人以渔
62 | 知识串讲:用一个创业故事串起操作系统原理(一)
63 | 知识串讲:用一个创业故事串起操作系统原理(二)
64 | 知识串讲:用一个创业故事串起操作系统原理(三)
65 | 知识串讲:用一个创业故事串起操作系统原理(四)
66 | 知识串讲:用一个创业故事串起操作系统原理(五)
67 | 期末测试:这些操作系统问题,你真的掌握了吗?
结束语 | 永远别轻视任何技术,也永远别轻视自己
免费
专栏加餐 (2讲)
学习攻略(一):学好操作系统,需要掌握哪些前置知识?
“趣谈Linux操作系统”食用指南
免费
趣谈Linux操作系统
登录|注册

35 | 块设备(下):如何建立代理商销售模式?

刘超 2019-06-17
文件系统那一节,我们讲了文件的写入,到了设备驱动这一层,就没有再往下分析。上一节我们又讲了 mount 一个块设备,将 block_device 信息放到了 ext4 文件系统的 super_block 里面,有了这些基础,是时候把整个写入的故事串起来了。
还记得咱们在文件系统那一节分析写入流程的时候,对于 ext4 文件系统,最后调用的是 ext4_file_write_iter,它将 I/O 的调用分成两种情况:
第一是直接 I/O。最终我们调用的是 generic_file_direct_write,这里调用的是 mapping->a_ops->direct_IO,实际调用的是 ext4_direct_IO,往设备层写入数据。
第二种是缓存 I/O。最终我们会将数据从应用拷贝到内存缓存中,但是这个时候,并不执行真正的 I/O 操作。它们只将整个页或其中部分标记为脏。写操作由一个 timer 触发,那个时候,才调用 wb_workfn 往硬盘写入页面。
接下来的调用链为:wb_workfn->wb_do_writeback->wb_writeback->writeback_sb_inodes->__writeback_single_inode->do_writepages。在 do_writepages 中,我们要调用 mapping->a_ops->writepages,但实际调用的是 ext4_writepages,往设备层写入数据。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈Linux操作系统》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 安排
    看了一点儿其它的资料,大概了解了一下,有以下几种情况:1、request_fn是在unplug泄流的时候调用(也就是队列里面的请求达到一定的数量) 2、或者是由定时器触发,也就是即使队列里面的请求很少,但是也不能无限期的不执行它们,所以在定时器超时后会调用request_fn 3、或者在添加request进行合并的时候,判断一下是哪种合并方式,如果是后向合并就会立即调用requset_fn。
    不知道这样理解的对不对?
    2019-06-17
    3
  • Geek_54edc1
    /sys/block/xvda/queue/scheduler 磁盘的调度算法,临时修改:echo noop > /sys/block/xvda/queue/scheduler,永久修改就需要修改内核参数,然后重启。
    iostat -d -x 中的avgqu-sz是平均I/O队列长度。

    作者回复: 赞

    2019-06-24
    1
  • Leon📷
    文件系统中的page_cache对应逻辑上的块的概念,将page_cache打包成bio递交给通用块设备层,通用块设备层将多个bio打包成一个请求request, 尽量把bio对应的sector临近的数据合并,提交给块设备调度层,块设备调度层就是把各个request当成段提交给设备驱动程序,因为设备驱动程序只识别段,也就是说通用块设备层捣腾的其实就是把bio对应的页框和在磁盘中对应的sector进行合并的过程,调度层只负责把合并的request放进队列,用调度算法下发给驱动程序处理,其实所有复杂的合并操作以及内存和磁盘扇区的对应关系都是通过块设备层做了,老师,可以这么理解吧

    作者回复: 是的

    2019-06-22
    1
  • 小美
    会不会断电丢失数据呢?

    作者回复: 会呀,flush就不会

    2019-06-19
    1
  • 安排
    make_request_fn被初始化成了blk_queue_bio函数。submit_bio会调用到generic_make_request,然后进一步调用到make_request_fn,也就是blk_queue_bio。在blk_queue_bio里面其实是先尝试将bio合并到当前进程的plug_list里面的request,如果可以合并,则合并后直接返回了,如果不能合并,则接着向磁盘设备的request_queue中合并,向request_queue中合并的时候一定会成功(因为即使不能合并也会新生成一个request)。而每个进程的plug_list里面的request也会在适当的时候就行泄流,泄流的时候会调用到磁盘设备的request_queue里面的电梯成员的elevator_add_req_fn,这个函数就是讲plug_list里面的request加入到request_queue里面的电梯队列里,进行更进一步的合并。
            设备驱动会调用request_queue的request_fn,平时写块设备驱动也就是申请一个request_queue,然后调用一些内核api初始化这个request_queue,并且实现自己的request_fn函数,request_fn会调用blk_peek_request从request_queue的queue_head成员取出request,并转化为更底层的指令来执行,如果发现queue_head为空,则会调用request_queue的elevator_dispatch_fn分发request。
    2019-06-18
    1
  • Leon📷
    那个队列,队头和队尾的合并都是为了所谓的顺序写,减少机械硬盘寻址消耗吧,能赶上就上同一辆车,赶不上自己叫一辆车等满了再走,但是也是有超时等待时间的,可以这么理解吧

    作者回复: 是的

    2019-06-17
    1
  • 安排
    往设备里面写的时候调用的是request_fn,这个函数是谁来调用的呢?触发这个调用的时机是什么呢?还是说请求一旦进入队列就会立即写入?

    作者回复: 会调用__blk_run_queue,里面调用request_fn

    2019-06-17
    1
  • hello
    太爽了,听了三四遍这节课,以前一直担心io在内核内部会发生多次拷贝,听完发现并没有。下一次我一定要边读源码边听。
    2019-09-26
  • 游弋云端
    老师,是否可以认为直接 IO执行完成后,数据就是下盘的,还是不一定,还有驱动层以及磁盘缓存等因素。

    作者回复: 还是需要设备驱动层的

    2019-09-01
  • 眭东亮
    查看磁盘调度算法
    cat /sys/block/sda/queue/scheduler

    作者回复: 赞

    2019-07-10
  • 安排
    老师,希望在答疑篇能讲一讲request_fn取出请求之后的具体执行过程,具体的执行是不是和block_device有关,磁盘的最底层的操作是不是都在block_device中?

    作者回复: 取出来之后,基本就是面向设备的操作了。

    2019-06-19
  • 安排
    直接读写裸设备不会走文件系统,那还会走通用块层吗?

    作者回复: 不会的

    2019-06-18
  • 石维康
    bio_list_merge(&bio_list_on_stack[0], &lower);
    bio_list_merge(&bio_list_on_stack[0], &same);
    bio_list_merge(&bio_list_on_stack[0], &bio_list_on_stack[1]);

    请问这些加到bio_list_on_stack[0]上的bio是在什么时候被处理的?

    作者回复: 后面会加回去的

    2019-06-17
收起评论
13
返回
顶部