linux查看磁盘条带化？

使用方法如下：

在终端输入 fdisk -l 命令，会列出当前系统中所有的磁盘设备。

在列表中选择要查看的磁盘设备，例如 /dev/sda。

输入 fdisk /dev/sda 命令，进入 fdisk 命令的交互模式。

输入 p 命令，查看磁盘的分区表。如果磁盘做了条带化，那么会显示多个分区，否则只会显示一个分区。

如果您有其他疑问，欢迎再次提问。

说起文件系统的演变与发展，不得不从最早期的 Minix *** 作系统开始说起。

Minix(MINI-UNIX) 是早期的一个迷你版本的 「类UNIX *** 作系统」 ，由荷兰阿姆斯特丹自由大学计算机科学系的塔能鲍姆教授自行开发的可以与UNIX *** 作系统兼容的一个 *** 作系统，因其小型，该 *** 作系统被命名为 MINIX 。

MINIX 系统在设计之初，采用程序模块化的思想，将一众程序放在用户空间运行，而不是在 *** 作系统的内核中运行。如 「文件系统」 和 「存储器管理」 等程序均是如此。

受 MINIX *** 作系统的影响，早期的Linux *** 作系统也曾采用由塔能鲍姆教授开发的MINIX的文件系统。

然而，不只因为早期的 MINIX *** 作系统并为真正意义上的开源软件(在保护著作的前提下进行收费)，而且基于 MINIX 的内部使用16位的偏移量，使文件系统能够支持的最大空间只有64MB，支持的最大文件名为14字符，导致后来 Linux *** 作系统转而开发出了 ext(Extended File System) 第一代可扩展文件系统。

ext(Extended File System) 为Linux系统最早的扩展文件系统，采用 「UNIX文件系统」 的元数据结构，克服了 「MINIX」 *** 作系统性能不佳的问题。

ext 文件系统采用 虚拟文件系统(VFS) ，最大可支持2GB的文件系统。与 MINIX 文件系统不同的是， ext 可以使用最高2GB的存储空间并同时处理255个字符的文件名。

但，在 ext 文件系统中，文件创建时生成的 inode 信息是不变的，这导致文件发生修改后 inode 中储存的文件时间戳并不会发生变化；而且 ext 并不会为文件妥善分配空间，磁盘上的多个文件四散分布，严重制约了文件系统的性能。

ext 文件系统推出后不久，其开发者便意识到 ext 文件系统中存在很大缺陷( inode不变性 和 文件空间碎片化 )，并在一年后推出了 ext2 (Second Extened File System) 第二代扩展文件系统，用来代替 ext 文件系统。

ext2 吸取了 「UNIX文件系统」 的众多优点，并且因其良好的可扩展性( 为系统在磁盘上存储的数据结构预留了很多空间提供给开发者使用 )，在20世纪90年代众多文件系统中脱颖而出。

众多新的特性， POSIX(可移植 *** 作系统接口) 、 访问控制表 等都是在这一代扩展文件系统上实现的。直至今天， POSIX 仍被众多 *** 作系统所沿用。

不仅如此， ext2 还在 ext 的基础上进行了完善，能够最大支持的单个文件达到 2TB。

ext2 文件系统与20世纪90年代的众多文件系统一样，将数据写入到磁盘的过程中如果发生系统奔溃或断电，极容易导致文件损坏或丢失。

正是因为类似 ext2 等同时期的一众文件系统，在遭遇系统奔溃或断电时会出现文件损坏或丢失。尽管 ext2 文件系统拥有开机后对文件系统中文件的一致性校验，但校验的过程极为耗时，且校验的过程中， *** 作系统上的任何卷组都是不可访问的。

然而 ext2 遗留的问题在 ext3(Third Extended File System) 中得到了解决。

ext3 文件系统采用日志记录的方式，记录下了 *** 作系统运行中的所有事件，这意味着即便遇到 *** 作系统非正常关机后也无须对文件系统进行校验，从而防止了文件系统中数据丢失的可能。

尽管 ext3 使用日志系统进行记录文件系统的变化，但这并没有影响 ext3 文件系统处理数据的速度。基于日志系统在磁盘上的优化，在 ext3 中数据的传输效率是高于 ext2 的，并且可以通过重新设置日志的级别来提升文件系统的性能。

其次， ext3 在设计之初就吸收了 ext2 的很多思想，这使得 ext2 文件系统迁移到 ext3 变得极为便利。事实上， ext3 可以在从 ext2 迁移 ext3 的过程中，无须进行文件系统资料的备份，且无须担心升级后的数据恢复问题。

也正是因为 ext3 设计之初沿用了众多 ext2 的功能，这使得 ext3 缺乏变通。例如， 「inode的动态分配」 和 「可变块大小」 等问题并没有得到解决。不仅如此， ext3 文件系统在被挂载为写入时，无法对文件系统进行完整性校验。

第四代扩展文件系统( Fourth Extended File System, ext4 ) 是继 ext3 文件系统的后续版本，不仅支持 ext3 的日志文件体系 ，同样支持 大文件系统 ，不仅提高了文件系统对于存储碎片化的抵抗，而且改进了 inode固一化 的问题。

同时， ext4 文件系统在开发之初就考虑到很多问题，对众多问题的优化和改进也使得 ext4 拥有了众多新的特性。例如， 大文件系统 、 使用Extent文件存储的方式 、 预分配空间 、 延迟文件获取空间的时间 、 突破原有子目录限制 、 增加日志校验和 、 在线整理磁盘 、 文件系统快速检查 、 向下兼容其他ext文件系统`。

时至今天， ext4 文件系统已经成为Linux发行版默认使用的文件系统。

与 ext2 文件系统同一时期出现的，还有 xfs 文件系统。 xfs 文件系统是高性能的文件系统，最早在 IRIX *** 作系统上开发，后期被移植到 Linux *** 作系统上。现在所有的 Linux发行版 都支持 xfs 的使用。

相比 32位 Linux 的 *** 作系统来说，64位 xfs 的文件系统能够支持的单个文件系统要远远超出 32位 *** 作系统。

xfs 对文件系统元数据提供了日志支持，当文件系统发生变化后，总是会保证源数据在数据块写入磁盘之前被写入日志中，磁盘中有一处缓冲区专门用来存放日志，从而不会影响正常的文件系统。

xfs 同样支持 「条带化分配」 。在条带化RAID阵列上创建 xfs 文件系统时，可以指定 条带化数据单元。通过配置条带化单元，使 数据分配、inode分配、日志等与RAID条带单元对齐，来提高文件系统的性能。

与 ext4 文件系统不同的是， xfs 文件系统还支持在线恢复。 xfs 文件系统提供了 xfsdump 和 xfsrestore 工具协助备份 xfs 文件系统中的数据。

以下为各文件系统的出现时间及特性：

参考自: https://zh.wikipedia.org/wiki/Ext4

磁盘结构与数据存储方式, 数据是如何存储的，又通过怎样的方式被访问？

机械硬盘主要由磁盘盘片、磁头、主轴与传动轴等组成；数据就存放在磁盘盘片中

现代硬盘寻道都是采用CHS( Cylinder Head Sector )的方式，硬盘读取数据时，读写磁头沿径向移动，移到要读取的扇区所在磁道的上方，这段时间称为 寻道时间(seek time) 。 因读写磁头的起始位置与目标位置之间的距离不同，寻道时间也不同 。磁头到达指定磁道后，然后通过盘片的旋转，使得要读取的扇区转到读写磁头的下方，这段时间称为 旋转延迟时间(rotational latencytime) 。然后再读写数据，读写数据也需要时间，这段时间称为 传输时间(transfer time) 。

固态硬盘主要由主控芯片、闪存颗粒与缓存组成；数据就存放在闪存芯片中

通过主控芯片进行寻址， 因为是电信号方式， 没有任何物理结构， 所以寻址速度非常快且与数据存储位置无关

如何查看系统IO状态

查看磁盘空间

调用 open , fwrite 时到底发生了什么?

在一个IO过程中，以下5个API/系统调用是必不可少的

Create 函数用来打开一个文件，如果该文件不存在，那么需要在磁盘上创建该文件

Open 函数用于打开一个指定的文件。如果在 Open 函数中指定 O_CREATE 标记，那么 Open 函数同样可以实现 Create 函数的功能

Clos e函数用于释放文件句柄

Write 和 Read 函数用于实现文件的读写过程

O_SYNC (先写缓存, 但是需要实际落盘之后才返回, 如果接下来有读请求, 可以从内存读 ), write-through

O_DSYNC (D=data, 类似O_SYNC, 但是只同步数据, 不同步元数据)

O_DIRECT (直接写盘, 不经过缓存)

O_ASYNC (异步IO, 使用信号机制实现, 不推荐, 直接用aio_xxx)

O_NOATIME (读取的时候不更新文件 atime(access time))

sync() 全局缓存写回磁盘

fsync() 特定fd的sync()

fdatasync() 只刷数据, 不同步元数据

mount noatime(全局不记录atime), re方式(只读), sync(同步方式)

一个IO的传奇一生 这里有一篇非常好的资料，讲述了整个IO过程；

下面简单记录下自己的理解的一次常见的Linux IO过程， 想了解更详细及相关源码，非常推荐阅读上面的原文

Linux IO体系结构

[站外图片上传中...(image-38a7b-1644137945193)]

Superblock 超级描述了整个文件系统的信息。为了保证可靠性，可以在每个块组中对superblock进行备份。为了避免superblock冗余过多，可以采用稀疏存储的方式，即在若干个块组中对superblock进行保存，而不需要在所有的块组中都进行备份

GDT 组描述符表 组描述符表对整个组内的数据布局进行了描述。例如，数据块位图的起始地址是多少？inode位图的起始地址是多少？inode表的起始地址是多少？块组中还有多少空闲块资源等。组描述符表在superblock的后面

数据块位图 数据块位图描述了块组内数据块的使用情况。如果该数据块已经被某个文件使用，那么位图中的对应位会被置1，否则该位为0

Inode位图 Inode位图描述了块组内inode资源使用情况。如果一个inode资源已经使用，那么对应位会被置1

Inode表 （即inode资源）和数据块。这两块占据了块组内的绝大部分空间，特别是数据块资源

一个文件是由inode进行描述的。一个文件占用的数据块block是通过inode管理起来的 。在inode结构中保存了直接块指针、一级间接块指针、二级间接块指针和三级间接块指针。对于一个小文件，直接可以采用直接块指针实现对文件块的访问；对于一个大文件，需要采用间接块指针实现对文件块的访问

最简单的调度器。它本质上就是一个链表实现的 fifo 队列，并对请求进行简单的 合并 处理。

调度器本身并没有提供任何可以配置的参数

读写请求被分成了两个队列， 一个用访问地址作为索引，一个用进入时间作为索引，并且采用两种方式将这些request管理起来；

在请求处理的过程中，deadline算法会优先处理那些访问地址临近的请求，这样可以最大程度的减少磁盘抖动的可能性。

只有在有些request即将被饿死的时候，或者没有办法进行磁盘顺序化 *** 作的时候，deadline才会放弃地址优先策略，转而处理那些即将被饿死的request

deadline算法可调整参数

read_expire : 读请求的超时时间设置(ms)。当一个读请求入队deadline的时候，其过期时间将被设置为当前时间＋read_expire，并放倒fifo_list中进行排序

write_expire :写请求的超时时间设置(ms)

fifo_batch :在顺序（sort_list）请求进行处理的时候，deadline将以batch为单位进行处理。每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中，不会产生是否超时的检查，也就不会产生额外的磁盘寻道时间。这个参数可以用来平衡顺序处理和饥饿时间的矛盾，当饥饿时间需要尽可能的符合预期的时候，我们可以调小这个值，以便尽可能多的检查是否有饥饿产生并及时处理。增大这个值当然也会增大吞吐量，但是会导致处理饥饿请求的延时变长

writes_starved :这个值是在上述deadline出队处理第一步时做检查用的。用来判断当读队列不为空时，写队列的饥饿程度是否足够高，以时deadline放弃读请求的处理而处理写请求。当检查存在有写请求的时候，deadline并不会立即对写请求进行处理，而是给相关数据结构中的starved进行累计，如果这是第一次检查到有写请求进行处理，那么这个计数就为1。如果此时writes_starved值为2，则我们认为此时饥饿程度还不足够高，所以继续处理读请求。只有当starved >= writes_starved的时候，deadline才回去处理写请求。可以认为这个值是用来平衡deadline对读写请求处理优先级状态的，这个值越大，则写请求越被滞后处理，越小，写请求就越可以获得趋近于读请求的优先级

front_merges :当一个新请求进入队列的时候，如果其请求的扇区距离当前扇区很近，那么它就是可以被合并处理的。而这个合并可能有两种情况，一个是向当前位置后合并，另一种是向前合并。在某些场景下，向前合并是不必要的，那么我们就可以通过这个参数关闭向前合并。默认deadline支持向前合并，设置为0关闭

在调度一个request时，首先需要选择一个一个合适的cfq_group。Cfq调度器会为每个cfq_group分配一个时间片，当这个时间片耗尽之后，会选择下一个cfq_group。每个cfq_group都会分配一个vdisktime，并且通过该值采用红黑树对cfq_group进行排序。在调度的过程中，每次都会选择一个vdisktime最小的cfq_group进行处理。

一个cfq_group管理了7棵service tree，每棵service tree管理了需要调度处理的对象cfq_queue。因此，一旦cfq_group被选定之后，需要选择一棵service tree进行处理。这7棵service tree被分成了三大类，分别为RT、BE和IDLE。这三大类service tree的调度是按照优先级展开的

通过优先级可以很容易的选定一类Service tree。当一类service tree被选定之后，采用service time的方式选定一个合适的cfq_queue。每个Service tree是一棵红黑树，这些红黑树是按照service time进行检索的，每个cfq_queue都会维护自己的service time。分析到这里，我们知道，cfq算法通过每个cfq_group的vdisktime值来选定一个cfq_group进行服务，在处理cfq_group的过程通过优先级选择一个最需要服务的service tree。通过该Service tree得到最需要服务的cfq_queue。该过程在 cfq_select_queue 函数中实现

一个cfq_queue被选定之后，后面的过程和deadline算法有点类似。在选择request的时候需要考虑每个request的延迟等待时间，选择那种等待时间最长的request进行处理。但是，考虑到磁盘抖动的问题，cfq在处理的时候也会进行顺序批量处理，即将那些在磁盘上连续的request批量处理掉

cfq调度算法的参数

back_seek_max :磁头可以向后寻址的最大范围，默认值为16M

back_seek_penalty :向后寻址的惩罚系数。这个值是跟向前寻址进行比较的

fifo_expire_async :设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理

fifo_expire_sync :这个参数跟上面的类似，区别是用来设置同步请求的超时时间

slice_idle :参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间，目的是提高机械硬盘的吞吐量。一般情况下，来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能

group_idle :这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下，我们可以将slice_idle ＝ 0而group_idle ＝ 8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生

low_latency :这个是用来开启或关闭cfq的低延时（low latency）模式的开关。当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slice time）进行重新计算。这将有利于对吞吐量的公平（默认是对时间片分配的公平）。关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的

target_latency :当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度

quantum :这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效

slice_sync :当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为： time_slice = slice_sync + (slice_sync/5 * (4 - prio)) 这个参数对同步请求有效

slice_async :这个值跟上一个类似，区别是对异步请求有效

slice_async_rq :这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的最大个数还跟相关进程被设置的io优先级有关

通常在Linux上使用的IO接口是同步方式的，进程调用 write / read 之后会阻塞陷入到内核态，直到本次IO过程完成之后，才能继续执行，下面介绍的异步IO则没有这种限制，但是当前Linux异步IO尚未成熟

目前Linux aio还处于较不成熟的阶段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是无法使用默认的Page Cache机制

正常情况下，使用aio族接口的简要方式如下：

io_uring 是 2019 年 5 月发布的 Linux 5.1 加入的一个重大特性 —— Linux 下的全新的异步 I/O 支持，希望能彻底解决长期以来 Linux AIO 的各种不足

io_uring 实现异步 I/O 的方式其实是一个生产者-消费者模型:

逻辑卷管理

RAID0

RAID1

RAID5（纠错）

条带化

Linux系统性能调整：IO过程

Linux的IO调度

一个IO的传奇一生

理解inode

Linux 文件系统是怎么工作的？

Linux中Buffer cache性能问题一探究竟

Asynchronous I/O and event notification on linux

AIO 的新归宿：io_uring

Linux 文件 I/O 进化史（四）：io_uring —— 全新的异步 I/O

---