手机随时阅读
新人专享大礼包¥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号