`

漫谈linux文件IO

    博客分类:
  • IO
 
阅读更多

这篇文章写的比较全面,也浅显易懂,备份下。转载自:http://blog.chinaunix.net/uid-27105712-id-3270102.html

在Linux 开发中,有几个关系到性能的东西,技术人员非常关注:进程,CPU,MEM,网络IO,磁盘IO。本篇文件打算详细全面,深入浅出。剖析文件IO的细节。从多个角度探索如何提高IO性能。本文尽量用通俗易懂的视角去阐述。不copy内核代码。

 

    阐述之前,要先有个大视角,让我们站在万米高空,鸟瞰我们的文件IO,它们设计是分层的,分层有2个好处,一是架构清晰,二是解耦。让我们看一下下面这张图。

 

clip_image002

图一

 

1.       穿越各层写文件方式

程序的最终目的是要把数据写到磁盘上, 但是系统从通用性和性能角度,尽量提供一个折中的方案来保证这些。让我们来看一个最常用的写文件典型example,也是路径最长的IO。

 

[cpp] view plaincopy
 
  1. {  
  2.     char *buf = malloc(MAX_BUF_SIZE);  
  3.   
  4.     strncpy(buf, src, , MAX_BUF_SIZE);  
  5.   
  6.     fwrite(buf, MAX_BUF_SIZE, 1, fp);  
  7.   
  8.     fclose(fp);  
  9. }   

 

这里malloc的buf对于图层中的application buffer,即应用程序的buffer;调用fwrite后,把数据从application buffer 拷贝到了 CLib buffer,即C库标准IObuffer。fwrite返回后,数据还在CLib buffer,如果这时候进程core掉。这些数据会丢失。没有写到磁盘介质上。当调用fclose的时候,fclose调用会把这些数据刷新到磁盘介质上。除了fclose方法外,还有一个主动刷新操作fflush函数,不过fflush函数只是把数据从CLib buffer 拷贝到page  cache 中,并没有刷新到磁盘上,从page cache刷新到磁盘上可以通过调用fsync函数完成。

 

从上面类子看到,一个常用的fwrite函数过程,基本上历经千辛万苦,数据经过多次copy,才到达目的地。有人心生疑问,这样会提高性能吗,反而会降低性能吧。这个问题先放一放。

 

有人说,我不想通过fwrite+fflush这样组合,我想直接写到page cache。这就是我们常见的文件IO调用read/write函数。这些函数基本上是一个函数对应着一个系统调用,如sys_read/sys_write. 调用write函数,是直接通过系统调用把数据从应用层拷贝到内核层,从application buffer 拷贝到 page cache 中。

 

系统调用,write会触发用户态/内核态切换?是的。那有没有办法避免这些消耗。这时候该mmap出场了,mmap把page cache 地址空间映射到用户空间,应用程序像操作应用层内存一样,写文件。省去了系统调用开销。

 

那如果继续刨根问底,如果想绕过page cache,直接把数据送到磁盘设备上怎么办。通过open文件带上O_DIRECT参数,这是write该文件。就是直接写到设备上。

 

如果继续较劲,直接写扇区有没有办法。这就是所谓的RAW设备写,绕开了文件系统,直接写扇区,想fdsikddcpio之类的工具就是这一类操作。

 

2.       IO调用链

列举了上述各种穿透各种cache 层写操作,可以看到系统提供的接口相当丰富,满足你各种写要求。下面通过讲解图一,了解一下文件IO的调用链。

fwrite是系统提供的最上层接口,也是最常用的接口。它在用户进程空间开辟一个buffer,将多次小数据量相邻写操作先缓存起来,合并,最终调用write函数一次性写入(或者将大块数据分解多次write调用)。

Write函数通过调用系统调用接口,将数据从应用层copy到内核层,所以write会触发内核态/用户态切换。当数据到达page cache后,内核并不会立即把数据往下传递。而是返回用户空间。数据什么时候写入硬盘,有内核IO调度决定,所以write是一个异步调用。这一点和read不同,read调用是先检查page cache里面是否有数据,如果有,就取出来返回用户,如果没有,就同步传递下去并等待有数据,再返回用户,所以read是一个同步过程。当然你也可以把write的异步过程改成同步过程,就是在open文件的时候带上O_SYNC标记。

数据到了page cache后,内核有pdflush线程在不停的检测脏页,判断是否要写回到磁盘中。把需要写回的页提交到IO队列——即IO调度队列。又IO调度队列调度策略调度何时写回。

提到IO调度队列,不得不提一下磁盘结构。这里要讲一下,磁头和电梯一样,尽量走到头再回来,避免来回抢占是跑,磁盘也是单向旋转,不会反复逆时针顺时针转的。从网上copy一个图下来,具体这里就不介绍。

clip_image003

IO队列有2个主要任务。一是合并相邻扇区的,而是排序。合并相信很容易理解,排序就是尽量按照磁盘选择方向和磁头前进方向排序。因为磁头寻道时间是和昂贵的。

这里IO队列和我们常用的分析工具IOStat关系密切。IOStat中rrqm/s wrqm/s表示读写合并个数。avgqu-sz表示平均队列长度。

内核中有多种IO调度算法。当硬盘是SSD时候,没有什么磁道磁头,人家是随机读写的,加上这些调度算法反而画蛇添足。OK,刚好有个调度算法叫noop调度算法,就是什么都不错(合并是做了)。刚好可以用来配置SSD硬盘的系统。

 

IO队列出来后,就到了驱动层(当然内核中有更多的细分层,这里忽略掉),驱动层通过DMA,将数据写入磁盘cache

至于磁盘cache时候写入磁盘介质,那是磁盘控制器自己的事情。如果想要睡个安慰觉,确认要写到磁盘介质上。就调用fsync函数吧。可以确定写到磁盘上了。

 

3.       一致性和安全性

谈完调用细节,再将一下一致性问题和安全问题。既然数据没有到到磁盘介质前,可能处在不同的物理内存cache中,那么如果出现进程死机,内核死,掉电这样事件发生。数据会丢失吗。

当进程死机后:只有数据还处在application cacheCLib cache时候,数据会丢失。数据到了page cache。进程core掉,即使数据还没有到硬盘。数据也不会丢失。

当内核core掉后,只要数据没有到达disk cache,数据都会丢失。

掉电情况呢,哈哈,这时候神也救不了你,哭吧。

 

那么一致性呢,如果两个进程或线程同时写,会写乱吗?或A进程写,B进程读,会写脏吗?

文章写到这里,写得太长了,就举出各种各样的例子。讲一下大概判断原则吧。fwrite操作的buffer是在进程私有空间,两个线程读写,肯定需要锁保护的。如果进程,各有各的地址空间。是否要加锁,看应用场景。

write操作如果写大小小于PIPE_BUF(一般是4096),是原子操作,能保证两个进程“AAA”,“BBB”写操作,不会出现“ABAABB”这样的数据交错。O_APPEND标志能保证每次重新计算pos,写到文件尾的原子性。

数据到了内核层后,内核会加锁,会保证一致性的。

 

4.       性能问题

性能从系统层面和设备层面去分析;磁盘的物理特性从根本上决定了性能。IO的调度策略,系统调用也是致命杀手。

磁盘的寻道时间是相当的慢,平均寻道时间大概是在10ms,也就是是每秒只能100-200次寻道。

磁盘转速也是影响性能的关键,目前最快15000rpm,大概就每秒500转,满打满算,就让磁头不寻道,设想所有的数据连续存放在一个柱面上。大家可以算一下每秒最多可以读多少数据。当然这个是理论值。一般情况下,盘片转太快,磁头感应跟不上,所以需要转几圈才能完全读出磁道内容。

另外设备接口总线传输率是实际速率的上限。

另外有些等密度磁盘,磁盘外围磁道扇区多,线速度快,如果频繁操作的数据放在外围扇区,也能提高性能。

利用多磁盘并发操作,也不失为提高性能的手段。

 

这里给个业界经验值:机械硬盘顺序写~30MB,顺序读取速率一般~50MB好的可以达到100M, SSD读达到~400MBSSD写性能和机械硬盘差不多。

 

Ps

O_DIRECT  RAW设备最根本的区别是O_DIRECT是基于文件系统的,也就是在应用层来看,其操作对象是文件句柄,内核和文件层来看,其操作是基于inode和数据块,这些概念都是和ext2/3的文件系统相关,写到磁盘上最终是ext3文件。

RAW设备写是没有文件系统概念,操作的是扇区号,操作对象是扇区,写出来的东西不一定是ext3文件(如果按照ext3规则写就是ext3文件)。

一般基于O_DIRECT来设计优化自己的文件模块,是不满系统的cache和调度策略,自己在应用层实现这些,来制定自己特有的业务特色文件读写。但是写出来的东西是ext3文件,该磁盘卸下来,mount到其他任何linux系统上,都可以查看。

而基于RAW设备的设计系统,一般是不满现有ext3的诸多缺陷,设计自己的文件系统。自己设计文件布局和索引方式。举个极端例子:把整个磁盘做一个文件来写,不要索引。这样没有inode限制,没有文件大小限制,磁盘有多大,文件就能多大。这样的磁盘卸下来,mount到其他linux系统上,是无法识别其数据的。

两者都要通过驱动层读写;在系统引导启动,还处于实模式的时候,可以通过bios接口读写raw设备。

分享到:
评论

相关推荐

    LinuxIO通信模型漫谈.pdf

    Linux IO 通信模型概述 在 Linux 系统中,IO 通信模型是网络编程的基础。理解不同的 IO 模型对于服务器领域的开发者非常重要。本文将从 Unix/Linux 接口出发,介绍几种常用的 IO 模型,并分析它们的优缺点。 阻塞...

    漫谈Linux兼容内核

    03:关于kernel-win32的文件操作.pdf 04:Kernel-win32的进程管理.pdf 05:Kernel-win32的系统调用机制.pdf 06:二进制映像的类型识别.pdf 07:Wine的二进制映像装入和启动.pdf 08:ELF映像的装入_一_.pdf 09:ELF...

    LinuxIO通信模型漫谈[整理].pdf

    Linux I/O 通信模型在软件开发中扮演着至关重要的角色,特别是在网络编程中。本文主要探讨了几种常见的I/O模型,以Unix/Linux平台上的Socket接口为例。首先,基础的网络编程通常涉及`listen()`, `send()`, `recv()`...

    漫谈Wine之二:Windows的文件操作

    ### 漫谈Wine之二:Windows的文件操作 #### 一、引言 Wine项目旨在让Windows应用程序能够在类Unix系统(如Linux)上运行,而不需实际安装Windows操作系统。为了更好地理解和实现这一目标,本文将深入探讨Windows与...

    Linux wine技术详解

    《漫谈Wine之二:Windows的文件操作.pdf》可能涵盖Wine如何处理Windows的文件路径、文件权限和文件系统接口。在Windows中,文件系统通常是NTFS或FAT,而在Linux中则是EXT系列或者其他类Unix系统常用的文件系统。Wine...

    漫谈兼容内核.zip

    漫谈兼容内核之三:Kernel-win32的文件操作 漫谈兼容内核之四:Kernel-win32的进程管理 漫谈兼容内核之五:Kernel-win32的系统调用机制 漫谈兼容内核之六:二进制映像的类型识别 漫谈兼容内核之七:Wine的二进制映像...

    漫谈兼容内核.7z

    谈兼容内核之一:ReactOS怎样实现系统调用.pdf 漫谈兼容内核之二:关于kernel -win32的对象管理.pdf 漫谈兼容内核之三:关于kernel-win32的文件操作.pdf 漫谈兼容内核之四:Kernel-win32的进程管理.pdf 漫谈兼容内核...

    漫谈兼容内核 电子版

    《漫谈兼容内核》是一本深入探讨操作系统内核,特别是Linux与Windows内核之间差异与共性的电子书籍。此书对于理解这两种广泛使用的操作系统核心的运作机制具有极高的价值。通过对内核的剖析,我们可以了解到操作系统...

    漫谈兼容内核[pdf]

    03.漫谈兼容内核之三:关于kernel-win32的文件操作.pdf 04.漫谈兼容内核之四:Kernel-win32的进程管理.pdf 05.漫谈兼容内核之五:Kernel-win32的系统调用机制.pdf 06.漫谈兼容内核之六:二进制映像的类型识别.pdf 07...

    漫谈兼容内核

    在“漫谈兼容内核”这一主题中,我们将深入探讨Linux和Windows两大操作系统底层的工作机制,并着重讨论如何实现它们之间的兼容性。 首先,让我们关注Linux内核。Linux是一种开源的操作系统内核,由林纳斯·托瓦兹于...

    漫谈Wine之三:Wine环境下的文件读写

    ### 漫谈Wine之三:Wine环境下的文件读写 #### 一、Wine简介及文件操作概述 Wine(Wine Is Not an Emulator)是一种兼容层技术,它允许用户在类Unix系统(如Linux或BSD)上运行Windows应用程序。Wine的核心思想是...

    漫谈兼容内核.rar

    Wine项目旨在使Linux等非Windows系统能够运行Windows应用程序。这部分可能讲述Wine如何解析PE文件,模拟Windows的环境,以及如何执行程序的初始化过程。 6. **Windows的APC机制** 异步过程调用(APC)是Windows...

    架构漫谈(王概凯架构系列文章整理)

    架构漫谈(一):什么是架构? 架构漫谈(二):认识概念是理解架构的基础 架构漫谈(三):如何做好架构之识别问题 架构漫谈(四):如何做好架构之架构切分 架构漫谈(五):什么是软件 架构漫谈(六):软件架构...

    03.漫谈兼容内核之三:关于kernel-win32的文件操作

    通过构建文件控制类和文件类对象,以及将Windows文件操作映射到Linux内核上,kernel-win32成功地在两种不同的操作系统之间架起了一座桥梁,使得Windows应用程序能够在Linux环境中运行,同时也保留了对文件操作的完整...

    华为防火墙技术漫谈.pdf

    华为防火墙技术漫谈,理论篇共包含十章,涵盖了会话与状态检测、安全策略、攻击防范、NAT、GRE 、L2TP 、IPSec 、SSL、双机热备、出口选路的原理、应用场景及配置方法

    漫谈兼容内核 毛德操

    《漫谈兼容内核》是毛德操先生的一本深入探讨操作系统内核兼容性问题的专业著作。这本书主要针对计算机科学中的核心主题——操作系统内核,尤其是如何实现不同系统间的兼容性,提供了丰富的理论知识和实践经验。 ...

    Windows之漫谈兼容内核

    漫谈兼容内核之三:Kernel-win32的文件操作 漫谈兼容内核之四:Kernel-win32的进程管理 漫谈兼容内核之五:Kernel-win32的系统调用机制 漫谈兼容内核之六:二进制映像的类型识别 漫谈兼容内核之七:Wine的二进制映像...

    漫谈Wine

    - **模拟文件操作**:Wine通过其动态链接库模拟Windows API中的文件操作函数,将Windows风格的文件路径转换为Linux风格的路径,然后调用Linux的系统调用来完成实际的文件读写操作。 - **路径映射**:Wine维护了一个...

    漫谈高数pdf(共十篇)

    《漫谈高数》系列文章深入探讨了高等数学的核心概念,尤其聚焦于级数理论及其在实际问题中的应用。在首篇文章《漫谈高数(一)泰勒级数的物理意义》中,作者巧妙地将复杂的数学原理与直观的物理意义相结合,使读者能够...

Global site tag (gtag.js) - Google Analytics