文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述 指向文件的引用的抽象化概念 。文件描述符在形式上是一个非负整数。 实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表 。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的 *** 作系统。
刚才说了，对于一次IO访问（以read举例），数据会先被拷贝到 *** 作系统内核的缓冲区中，然后才会从 *** 作系统内核的缓冲区拷贝到应用程序的地址空间。所以说，当一个read *** 作发生时，它会经历两个阶段：
1、等待数据准备 (Waiting for the data to be ready)
2、将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)
正式因为这两个阶段，linux系统产生了下面 五种网络模式 的方案。
阻塞 I/O（blocking IO）
非阻塞 I/O（nonblocking IO）
I/O 多路复用（ IO multiplexing）
异步 I/O（asynchronous IO）
信号驱动 I/O（ signal driven IO）
注：由于signal driven IO在实际中并不常用，所以我这只提及剩下的四种IO Model。
阻塞 I/O（blocking IO）
在linux中，默认情况下所有的socket都是blocking，一个典型的读 *** 作流程大概是这样：
当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到 *** 作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。
所以，blocking IO的特点就是在IO执行的两个阶段都被block了（内核阻塞读取数据，内核将数据复制到应用户态）。
非阻塞 I/O（nonblocking IO）
linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读 *** 作时，流程是这个样子：
当用户进程发出read *** 作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read *** 作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read *** 作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，nonblocking IO的特点是用户进程需要 不断的主动询问 kernel数据好了没有（ 内核读取数据时，用户态不需要阻塞，内核将数据复制到用户态时，需要阻塞 ）。
I/O 多路复用（ IO multiplexing）
IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是 select，poll，epoll这个function会不断的轮询所负责的所有socket ，当某个socket有数据到达了，就通知用户进程。
当用户 进程调用了select ， 那么整个进程会被block ，而同时，kernel会“监视”所有 select负责的socket（一个管理多个socket连接），当任何一个socket中的数据准备好了，select就会返回 。这个时候用户进程再调用read *** 作， 将数据从kernel拷贝到用户进程 。
所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。
这个图和blocking IO的图其实并没有太大的不同，事实上，还更差一些。 因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom) 。但是，用select的优势在于它可以同时处理多个connection。
所以，如果处理的 连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大 。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。
总结：IO多路复用其实也是阻塞的，阻塞的地方在用当有socket连接有数据以后， 会阻塞知道数据从内核复制到用户态（第二步阻塞）。
异步 I/O（asynchronous IO）
inux下的asynchronous IO其实用得很少。先看一下它的流程：
用户进程发起read *** 作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read *** 作完成了。
总结：两个阶段都不需要用户进程干涉，内核将数据准备好以后通知用户态去读取
总结
blocking和non-blocking的区别
调用blocking IO会一直block住对应的进程直到 *** 作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。
synchronous IO和asynchronous IO的区别
在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。POSIX的定义是这样子的：
- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes
- An asynchronous I/O operation does not cause the requesting process to be blocked
两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的 blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO 。
有人会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO *** 作，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。但是， 当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。
而asynchronous IO则不一样，当进程发起IO *** 作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。
上文学到 不管什么文件系统类型，都通过VFS(虚拟文件系统层)读和写等 *** 作文件，写文件的元数据和文件的实际数据到磁盘 。但数据是怎么落地磁盘中的呢？落到磁盘中的都经过什么组件？
以一个写数据到磁盘为例，给出Linux I/O子系统的体系结构。
当磁盘执行写入 *** 作时发生的 基本 *** 作 (假设磁盘上扇区中的文件数据已经被读取到分页缓存)。
1) 一个进程通过write()系统调用 VFS虚拟文件系统 请求写一个文件。
2) 内核更新已映射文件的分页缓存。
3) 内核线程 pdflush/Per-BDI flush将分页缓存刷新到磁盘。
4) 同时 VFS虚拟文件系统层 在一个bio(block input output)结构中放置每个块缓冲，并向块设备层提交写请求。
5) 块设备层 从上层得到请求，并执行一个 I/O电梯 *** 作，将请求放置到I/O 请求队列。
6) 设备驱动器 （比如SCSI 或 其他设备特定的驱动器）将执行写 *** 作。
7) 磁盘设备 固件执行硬件 *** 作，如在盘片扇区上定位磁头，旋转，数据传输。
过去的20年中，处理器性能的改进要超过计算机系统中的其他组件，如处理器缓存、物理内存及磁盘等等。 访问内存和磁盘的速度较慢会限制整个系统的性能 ，怎么解决这个问题呢？引入 磁盘缓存机制 ，在较快的存储器中缓存频繁使用的数据，减少了访问较慢的存储器的次数。
磁盘缓存机制有以下3个地方解决：
引入存储层次结构 ，在CPU和磁盘之间放置L1缓存、L2缓存、物理内存和一些其他缓存减少这种不匹配，从而让进程减少访问较慢的内存和磁盘的次数，避免CPU花费更多的时间等待来自较慢磁盘驱动器的数据。
另外一种解决思路： 在更快的存储器上实现更高的缓存命中率，就可能更快地访问数据 。怎么提高缓存命中率呢？引入 参考局部性(locality of reference) 的技术。这项技术基于以下2个原则：
1) 大多数最近使用过的数据，在不久的将来有较高的几率被再次使用(时间局部性)。
2) 驻留在数据附近的数据有较高的几率被再次使用(空间局部性)。
Linux在许多组件中使用这些原则，比如分页缓存、文件对象缓存（索引节点缓存、目录条目缓存等等）、预读缓冲等。
以进程从磁盘读取数据并将数据复制到内存的过程为例。进程可以从缓存在内存中的数据副本中检索相同的数据，用于读和写。
1) 进程写入新数据
当一个进程试图改变数据时，进程首先在内存中改变数据。此时磁盘上的数据和内存中的数据是不相同的，并且内存中的数据被称为 脏页(dirty page) 。脏页中的数据应该尽快被同步到磁盘上，因为如果系统突然发生崩溃(电源故障)则内存中的数据会丢失。
2) 将内存中的数据刷新到磁盘
同步脏数据缓冲的过程被称为 刷新 。在Linux 2.6.32内核之前(Red Hat Enterprise Linux 5)，通过内核线程pdflush将脏页数据刷新到磁盘。在Linux 2.6.32内核中(Red Hat Enterprise Linux 6.x)pdflush被Per-BDI flush线程(BDI=Backing Device Interface)取代，Per-BDI flush线程以flush-MAJOR：MINOR的形式出现在进程列表中。当内存中脏页比例超过阀值时，就会发生刷新(flush)。
块层处理所有与块设备 *** 作相关的活动。块层中的关键数据结构是bio(block input output)结构，bio结构是在虚拟文件系统层和块层之间的一个接口。
当执行写的时候，虚拟文件系统层试图写入由块缓冲区构成的页缓存，将连续的块放置在一起构成bio结构，然后将其发送到块层。
块层处理bio请求，并链接这些请求进入一个被称为I/O请求的队列。这个链接的 *** 作被称为 I/O电梯调度(I/O elevator)。问个问题：为啥叫电梯调度呢？
Linux 2.4内核使用的是一种单一的通用I/O电梯调度方法，2.6内核提供4种电梯调度算法供用户自己选择。因为Linux *** 作系统适用的场合很广泛，所以I/O设备和工作负载特性都会有明显的变化。
1）CFQ(Complete Fair Queuing，完全公平队列)
CFQ电梯调度为每个进程维护一个I/O队列，从而 对进程实现一个QoS(服务质量)策略 。CFQ电梯调度能够很好地适应存在很多竞争进程的大型多用户系统。它积极地避免进程饿死并具有低延迟特征。从2.6.18内核发行版开始，CFQ电梯调度成为默认I/O调度器。
CFQ为每个进程/线程单独创建一个队列来管理产生的请求，各队列之间用时间片来调度，以保证每个进程都能分配到合适的I/O带宽。I/O调度器每次执行一个进程的4个请求。
2）Deadline
Deadline是一种循环的电梯调度(round robin)方法，Deadline 算法实现了一个近似于实时的I/O子系统。在保持良好的磁盘吞吐量的同时，Deadline电梯调度既提供了出色的块设备扇区的顺序访问，又确保一个进程不会在队列中等待太久导致饿死。
Deadline调度器为了兼顾这两个方面，引入了4个队列，这4个队列可分为两类，每一类都由读和写两种队列组成。一类队列用来对 请求 按 起始扇区序号 进行排序（通过红黑树来组织），称为sort_list；另一类对 请求 按 生成时间进行排序 （由链表来组织），称为fifo_list。每当确定了一个传输方向（读或写），系统都将会从相应的sort_list中将一批连续请求调度到请求队列里，具体的数目由fifo_batch来确定。 只有遇到三种情况才会导致一次批量传输的结束 ：1.对应的sort_list中已经没有请求了；2.下一个请求的扇区不满足递增的要求；3.上一个请求已经是批量传输的最后一个请求了。
所有的请求在生成时都会被赋上一个期限值，并且按期限值将它们排序在fifo_list中， 读请求的期限时长默认为500ms，写请求的期限时长默认为5s。 在Deadline调度器定义了一个writes_starved默认值为2，写请求的饥饿线。 内核总是优先处理读请求，当饿死进程的次数超过了writes_starved后，才会去考虑写请求 。 为什么内核会偏袒读请求呢? 这是从整体性能上进行考虑的。读请求和应用程序的关系是同步的，因为应用程序要等待读取完毕，方能进行下一步工作所以读请求会阻塞进程，而写请求则不一样。应用程序发出写请求后，内存的内容何时被写入块设备对程序的影响并不大，所以调度器会优先处理读请求。
3) NOOP
一个简单的FIFO 队列，不执行任何数据排序。NOOP 算法简单地合并相邻的数据请求，所以增加了少量的到磁盘I/O的处理器开销。NOOP电梯调度假设一个块设备拥有它自己的电梯算法。当后台存储设备能重新排序和合并请求，并能更好地了解真实的磁盘布局时，通常选择NOOP调度，
4）Anticipatory
Anticipatory本质上与Deadline一样，但Anticipatory电梯调度在处理最后一个请求之后会等待一段很短的时间，约6ms(可调整antic_expire改变该值)，如果在此期间产生了新的I/O请求，它会在每个6ms中插入新的I/O *** 作，这样可以将一些小的I/O请求合并成一个大的I/O请求，从而用I/O延时换取最大的I/O吞吐量。
Linux内核使用设备驱动程序得到设备的控制权。 设备驱动程序 通常是一个独立的内核模块，通常针对每个设备(或是设备组)而提供，以便这些设备在Linux *** 作系统上可用。一旦加载了设备驱动程序，将被当作Linux内核的一部分运行，并能控制设备的运行。
SCSI (Small Computer System Interface，小型计算机系统接口)是最常使用的I/O设备技术，尤其在企业级服务器环境中。SCSI在 Linux 内核中实现，可通过设备驱动模块来控制SCSI设备。 SCSI包括以下模块类型 ：
1) Upper IeveI drivers(上层驱动程序)。 sd_mod、sr_mod（SCSI-CDROM）、st（SCSI Tape）和sq（SCSI通用设备）等。
2) MiddIe IeveI driver(中层驱动程序) 。如scsi_mod实现了 SCSI 协议和通用SCSI功能。
3) Low IeveI drivers(底层驱动程序) 。提供对每个设备的较低级别访问。底层驱动程序基本上是特定于某一个硬件设备的，可提供给某个设备。
4) Pseudo drive(伪驱动程序) 。如ide-scsi，用于 IDE-SCSI仿真。
通常一个较大的性能影响是文件系统元数据怎样在磁盘上存放 。引入 磁盘条带阵列 (RAID 0、RAID 5和RAID 6)解决这个问题。在一个条带阵列上，磁头在移动到阵列中下一个磁盘之前，单个磁盘上写入的数据称为 CHUNKSIZE ，所有磁盘使用一次它后返回到第一个磁盘。 如果文件系统的布局没有匹配RAID的设计，则有可能会发生一个文件系统元数据块被分散到2个磁盘上，导致对2个磁盘发起请求 。或者 将所有的元数据在一个单独的磁盘上存储，如果该磁盘发生故障则可能导致该磁盘变成热点 。
设计RAID阵列需要考虑以下内容：
1) 文件系统使用的块大小。
2) RAID 阵列使用的CHUNK大小。
3) RAID 阵列中同等磁盘的数量。
块大小 指可以读取/写入到驱动器的最小数据量，对服务器的性能有直接的影响。块的大小由文件系统决定，在联机状态下不能更改，只有重新格式化才能修改。可以使用的块大小有1024B、2048B、4096B，默认为 4096 B。
stride条带 是在一个chunk中文件系统块的数量。如果文件系统块大小为4KB，则chunk大小为64KB，那么stride是64KB/4KB=16块。
stripe-width 是RAID阵列上一个条带中文件系统块的数量。比如 一个3块磁盘的RAID5阵列 。按照定义，在RAID5阵列每个条带中有1个磁盘包含奇偶校验内容。想要得到stripe-width，首先需要知道每个条带中有多少磁盘实际携带了数据块，即3磁盘-1校验磁盘=2数据磁盘。2个磁盘中的stride是chunk中文件系统块的数量。因此能计算 2（磁盘）*16（stride）=32（stripe）。
创建文件系统时可以使用mkfs给定数量：mk2fs -t ext4 -b 4096 -E stripe=16,stripe_width=64 /dev/vda
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）