手机随时阅读
新人专享大礼包￥24
续《一个IO的传奇一生（13）—— Linux中的MD开源RAID（1）》 4.6 make_request函数说明函数原型：static int make_request (request_queue_t *q, struct bio * bi)参数：*q，请求队列
1、前言 RAID是IO路径中的关键模块，甚至在整个存储系统中，RAID是最为核心和复杂的模块。在Linux操作系统中，提供了一个开源的RAID，那就是MD RAID。该RAID可以实现RAID0、RAID1、RAID5和RAID6的功能，在产业界得到了广泛的应用。MD RAID对外采用块设备的形式导出，因此，通过块设备层的调度，BIO请求会被发送到RAID模块进行进一步的IO处理。在M
从技术研发者角度看RAID 在一个IO的旅程中基本上都会经历一个非常重要站点，他就是RAID。提起RAID，基本上是无人不晓，每个人都能说上一点。例如RAID5、RAID6之类的概念，此外，RAID可以提高数据可靠性，但是考虑到IO 性能等问题，很多人都会采用硬件RAID卡对IO进行加速。诸如此类的东西，或许大家都知道。从表面上看，RAID似乎很简单，多块磁盘聚合在一起，采用一
辗转反侧，一个IO终于从应用层达到了IO Scheduler层，并且经过scheduler调度处理之后准备前往SCSI层，向目的地Disk方向前进。一个IO历尽千辛万苦从应用层来到IO调度器，正准备调度走，回眸往事，不禁潸然泪下，路漫漫，一路走来真是不易！从应用层走到文件系统；在文件系统的Cache中停留许久之后，又被Writeback线程写入到块设备层；经过块设备层的调度处理之后，终于
CFQ调度器算法 在相对比较老的Linux中，CFQ机制的实现还比较简单，仅仅是针对不同的thread进行磁盘带宽的公平调度。但是，自从新Kernel引入Cgroup机制之后，CFQ的机制就显得比较复杂了，因为，此时的CFQ不仅可以对IO带宽进行公平调度，更重要的是对磁盘IO进行QoS控制。IO的QoS控制是非常必要的，在同一系统中，不同进程/线程所享有的IO带宽可以是不同的，为了达到此
Linux中常见IO调度器Noop调度器算法 Noop是Linux中最简单的调度器，这个调度器基本上没做什么特殊的事情，就是把邻近bio进行了合并处理。从IO的QoS角度来看，这个Noop调度器就是太简单了，但是从不同存储介质的特性来看，这个Noop还是有一定用武之地的。例如，对于磁盘介质而言，为了避免磁头抖动，可以通过调度器对写请求进行合并。对于SSD存储介质而言，这个问题不存在了，或
Elevator子系统介绍Elevator子系统是IO 路径上非常重要的组成部分，前面已经分析过，elevator中实现了多种类型的调度器，用于满足不同应用的需求。那么，从整个IO路径的角度来看，elevator这层主要解决IO的QoS问题，通常需要解决如下两大问题：1）Bio的合并问题。主要考虑bio是否可以和scheduler中的某个request进行合并。因为从磁盘的角度来看，临近
IO调度器设计考虑 通过前面的分析已经知道IO调度器主要是为了解决临近IO合并的问题。磁介质存储盘最大的性能瓶颈在于寻道。当用户访问一个指定地址时，磁盘首先需要进行寻道操作，找到访问地址所属的区域。这种操作往往是毫秒级别的，相对于性能不断提升的CPU而言，这种性能显然是不可接受的。所以，磁盘最大的问题在于机械操作引入的寻道时间过长，对外表现就是随机读写性能太差了。 为了弥补这种
IO调度器 当IO旅行到调度器的时候，发现自己受到的待遇竟然很不一样，有些IO倚仗着特权很快就放行了；有些IO迟迟得不到处理，甚至在有些系统中居然饿死！面对这样的现状，IO显然是很不高兴的，凭什么别人就能被很快送到下一个旅程，自己需要在调度器上耗费青春年华？这里是拼爹的时代，人家出身好，人家是读请求，人家就可以很快得到资源。咱们是写请求，出生贫寒，只能等着，但也不会让你饿死。这就是我们常
块设备层分析无论是经过EXT3文件系统还是块设备文件,最终都要通过writeback机制将数据刷新到磁盘，除非用户在对文件进行读写的时候采用了DirectIO的方式。为了提高性能，文件系统或者是裸设备都会采用Linux的cache机制对数据读写性能进行优化，因此都会采用writeback回写机制将数据写入磁盘。通过上述分析我们已经知道，writeback机制会调用不同底层设备的address_sp
块设备buffer cache机制 在EXT3文件IO踏上新的征程之前，需要介绍一位EXT3文件IO的同伴，他们即将踏上相同的旅程。只不过这位同伴没有经历过EXT3文件系统的精彩，却领略了另外一番略有差别的风情。这位同伴是在块设备写操作时创建诞生的，我们可以称它为块设备IO。在很多应用中都会直接进行块设备操作，我们常用的命令dd就可以进行块设备的读写。例如：dd&n
数据回写对于EXT3文件系统而言，在绝大多数情况下，IO请求走到page cache之后就认为这个IO处理已经完成了。用户的IO请求被放入Cache之后，用户操作结束。实际上，此时的IO处境非常的危险，如果系统在此时Crash，那么内存中缓存的数据将会彻底丢失。为了保证数据不丢失，需要有一种机制及时的将缓存中的数据同步（回写）到磁盘。对于2.6.23版本的Linux，采用了Pdflush
EXT3文件写操作 如果应用层发起的是一个Word文档的写操作请求，那么通过上述分析，IO会走到sys_write的地方，然后执行file->f_op->write方法。对于EXT3 ，该方法注册的是do_sync_write。Do_sync_write的实现如下：ssize_t do_sync_write(struct file *filp, const char
前言前几天同事提议写一篇文章来仔细分析一下一个IO从创建到消亡的整个过程，我觉得这个想法很好，一个IO从创建到消亡经历了千山万水，从软件到硬件涉及到很多很多的技术。一个看似简单的IO读写操作，其实汇集了从计算机软件技术、硬件技术、电子技术、信号处理等各个方面的内容。所以，我想把IO的一生通过自己的认识把他描述一下，让世人看清在执行一个简单的IO操作究竟汇集了多少的智慧！汇集了工程师、科学家多少的心
Copyright © 2005-2022 51CTO.COM 版权所有 京ICP证060544号
