学生信的那些事儿之七 - Linux基础之Shell脚本编程

Posted 2023-04-28

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了学生信的那些事儿之七 - Linux基础之Shell脚本编程相关的知识，希望对你有一定的参考价值。

参考技术A 沿着前面的轨迹，接下来是Linux中shell脚本的学习。这对于生信工程师后续处理大量 (海量更合适些) 数据是非常非常重要的，但是同样的，作为一个有点古板的人，对于"脚本"是什么意思我都死磕了好久。主要觉得有些抽象，尤其是跟生信的同事讨论项目分析部分的问题时，他们经常会说道这个词，在他们意识里这是个不言自明的术语，殊不知对外行人而言 (比如我)，那简直就是无情的"知识的诅咒"。经常是我假装听懂了，然后继续讨论下面的问题，形成一个模糊的印象。

百度上的解释是：脚本（Script）是一种批处理文件的延伸，是一种纯文本保存的程序，一般来说的计算机脚本程序是确定的一系列控制计算机进行运算操作动作的组合，在其中可以实现一定的逻辑分支等。不知道你能不能看懂，反正我开始的时候真是一知半解。

鸟哥私房菜的解释是：shell script是利用 shell 的功能所写的一个"程序"，这个程序是使用纯文本文件，将一些shell的语法与命令(含外部命令)写在里面，搭配正则表达式、管道命令与数据流重定向等功能，以达到我们所想要的处理的目的。不明觉厉，好像更看不懂了···

Jude 的简单粗暴大白话解释是：脚本就是Linux中很多命令按照一定规则的组合，以实现某个特定的功能。Linux中有很多简单的命令，往往只是进行了简单的对话，比如 cd 就是进入到某个目录，简单直接。但是如果我想进入某个目录A，然后在目录A中创建目录B，再在目录B中创建文本C呢？当然可以一步一步操作，如果想要一步到位呢，那就可以用脚本，把三个命令写在一起，一起执行。好像有点啰嗦···

或者从英语的角度去理解，脚本的对应英文是Script，而这个单词的中文释义中还有剧本的意思。剧本就好理解了啊，剧本就是导演(生信工程师)基于某个主旨(要实现的目标)按照一定的手法(规则)所写的一个故事。不管是哪个演员，都得按照剧本演。所以，学好英语对于生信也是有帮助的~

按照脚本的复杂程度可以分为：

这个无需多说，其实就是若干个简单命令的顺序排列，执行脚本后会按照命令的前后关系从前往后一一执行。

相对于简单的基本脚本，结构化的命令脚本可以施加逻辑流程控制，从而改变程序(命令)执行的顺序。基本脚本中的命令就是从上往下执行，但是结构化的命令脚本可以根据逻辑判断重复或者跳过某些命令。

常用的结构化命令(语句)有：

后面还有什么嵌套循环啊啥的，不过我觉得上面的7中命令学到家了，应该可以应付大部分在生信分析里面的应用了。

记得高中的时候，物理老师(也是班主任)在给我们讲解习题时有个有意思的套路：不管什么难题现在下面写个"答："，以示自己解决问题的决心，也是一种正向的心理暗示。脚本编写也是有套路的，不过总的来说还是比较简单。

对于简单的脚本(超级简单的那种)，直接几个命令连在一起即可，中间用"；"隔开。

对于更长更复杂的脚本，一般需要创建一个文本，并在里面编辑。这就涉及到了文本编辑器，比较常用和简单的一般有nano和vim，实在很简单，规则也容易理解，教程随手可得，不多说。

比如用vim创建了一个脚本之后，具体的语法(套路)：

ok，脚本写完了，怎么让脚本开始工作呢？这有涉及到之前讲过的环境变量和相对路径、绝对路径了。方法有三：

就这么多吧，应该有点感觉到了，剩下的就是狂练狂练了~

超深度解析 Linux I/O 的那些事儿

本文主要以一张图为基础，向大家介绍 Linux在 I/O 上做了哪些事情，即 Linux 中直接 I/O 原理，希望本文的经验和思路能为读者提供一些帮助和思考。

我们先看一张图：

超深度解析

这张图大体上描述了 Linux 系统上，应用程序对磁盘上的文件进行读写时，从上到下经历了哪些事情。

这篇文章就以这张图为基础，介绍 Linux 在 I/O 上做了哪些事情。

文件系统

什么是文件系统

文件系统，本身是对存储设备上的文件，进行组织管理的机制。组织方式不同，就会形成不同的文件系统。比如常见的 Ext4、XFS、ZFS 以及网络文件系统 NFS 等等。

但是不同类型的文件系统标准和接口可能各有差异，我们在做应用开发的时候却很少关心系统调用以下的具体实现，大部分时候都是直接系统调用 open, read, write, close 来实现应用程序的功能，不会再去关注我们具体用了什么文件系统（UFS、XFS、Ext4、ZFS），磁盘是什么接口（IDE、SCSI，SAS，SATA 等），磁盘是什么存储介质（HDD、SSD）。

应用开发者之所以这么爽，各种复杂细节都不用管直接调接口，是因为内核为我们做了大量的有技术含量的脏活累活。开始的那张图看到 Linux 在各种不同的文件系统之上，虚拟了一个 VFS，目的就是统一各种不同文件系统的标准和接口，让开发者可以使用相同的系统调用来使用不同的文件系统。

文件系统如何工作（VFS）

Linux 系统下的文件

在 Linux 中一切皆文件。不仅普通的文件和目录，就连块设备、套接字、管道等，也都要通过统一的文件系统来管理。

用 ls -l 命令看最前面的字符可以看到这个文件是什么类型


brw-r--r-- 1 root    root    1, 2 4月  25 11:03 bnod // 块设备文件
crw-r--r-- 1 root    root    1, 2 4月  25 11:04 cnod // 符号设备文件
drwxr-xr-x 2 wrn3552 wrn3552    6 4月  25 11:01 dir // 目录
-rw-r--r-- 1 wrn3552 wrn3552    0 4月  25 11:01 file // 普通文件
prw-r--r-- 1 root    root       0 4月  25 11:04 pipeline // 有名管道
srwxr-xr-x 1 root    root       0 4月  25 11:06 socket.sock // socket文件
lrwxrwxrwx 1 root    root       4 4月  25 11:04 softlink -> file // 软连接
-rw-r--r-- 2 wrn3552 wrn3552 0 4月  25 11:07 hardlink // 硬链接（本质也是普通文件）

Linux 文件系统设计了两个数据结构来管理这些不同种类的文件：

inode(index node)：索引节点
dentry(directory entry)：目录项

inode 和 dentry

inode

inode 是用来记录文件的 metadata，所谓 metadata 在 Wikipedia 上的描述是 data of data，其实指的就是文件的各种属性，比如 inode 编号、文件大小、访问权限、修改日期、数据的位置等。

wrn3552@novadev:~/playground$ stat file
  文件：file
  大小：0               块：0          IO 块：4096   普通空文件
设备：fe21h/65057d      Inode：32828       硬链接：2
权限：(0644/-rw-r--r--)  Uid：( 3041/ wrn3552)   Gid：( 3041/ wrn3552)
最近访问：2021-04-25 11:07:59.603745534 +0800
最近更改：2021-04-25 11:07:59.603745534 +0800
最近改动：2021-04-25 11:08:04.739848692 +0800
创建时间：-

inode 和文件一一对应，它跟文件内容一样，都会被持久化存储到磁盘中。所以，inode 同样占用磁盘空间，只不过相对于文件来说它大小固定且大小不算大。

dentry

dentry 用来记录文件的名字、inode 指针以及与其他 dentry 的关联关系。

wrn3552@novadev:~/playground$ tree
.
├── dir
│   └── file_in_dir
├── file
└── hardlink

文件的名字：像 dir、file、hardlink、file_in_dir 这些名字是记录在 dentry 里的
inode 指针：就是指向这个文件的 inode
与其他 dentry 的关联关系：其实就是每个文件的层级关系，哪个文件在哪个文件下面，构成了文件系统的目录结构

不同于 inode，dentry 是由内核维护的一个内存数据结构，所以通常也被叫做 dentry cache。

文件是如何存储在磁盘上的

超深度解析

这里有张图解释了文件是如何存储在磁盘上的，首先，磁盘再进行文件系统格式化的时候，会分出来 3 个区：

Superblock
inode blocks
data blocks

（其实还有 boot block，可能会包含一些 bootstrap 代码，在机器启动的时候被读到，这里忽略）其中 inode blocks 放的都是每个文件的 inode，data blocks 里放的是每个文件的内容数据。这里关注一下 superblock，它包含了整个文件系统的 metadata，具体有：

inode/data block 总量、使用量、剩余量
文件系统的格式，属主等等各种属性

superblock 对于文件系统来说非常重要，如果 superblock 损坏了，文件系统就挂载不了了，相应的文件也没办法读写。既然 superblock 这么重要，那肯定不能只有一份，坏了就没了，它在系统中是有很多副本的，在 superblock 损坏的时候，可以使用 fsck（File System Check and repair）来恢复。回到上面的那张图，可以很清晰地看到文件的各种属性和文件的数据是如何存储在磁盘上的：

dentry 里包含了文件的名字、目录结构、inode 指针
inode 指针指向文件特定的 inode（存在 inode blocks 里）
每个 inode 又指向 data blocks 里具体的 logical block，这里的 logical block 存的就是文件具体的数据

这里解释一下什么是 logical block：

对于不同存储介质的磁盘，都有最小的读写单元

/sys/block/sda/queue/physical_block_size

HDD 叫做 sector（扇区），SSD 叫做 page（页面）
对于 hdd 来说，每个 sector 大小 512Bytes
对于 SSD 来说每个 page 大小不等（和 cell 类型有关），经典的大小是 4KB
但是 Linux 觉得按照存储介质的最小读写单元来进行读写可能会有效率问题，所以支持在文件系统格式化的时候指定 block size 的大小，一般是把几个 physical_block 拼起来就成了一个 logical block

/sys/block/sda/queue/logical_block_size

理论上应该是 logical_block_size >= physical_block_size，但是有时候我们会看到 physical_block_size = 4K，logical_block_size = 512B 情况，其实这是因为磁盘上做了一层 512B 的仿真（emulation）（详情可参考 512e 和 4Kn）

ZFS

这里简单介绍一个广泛应用的文件系统 ZFS，一些数据库应用也会用到 ZFS，先看一张 zfs 的层级结构图：

超深度解析

这是一张从底向上的图：

将若干物理设备 disk 组成一个虚拟设备 vdev（同时，disk 也是一种 vdev）
再将若干个虚拟设备 vdev 加到一个 zpool 里
在 zpool 的基础上创建 zfs 并挂载（zvol 可以先不看，我们没有用到）

ZFS 的一些操作

创建 zpool

root@:~ # zpool create tank raidz /dev/ada1 /dev/ada2 /dev/ada3 raidz /dev/ada4 /dev/ada5 /dev/ada6
root@:~ # zpool list tank
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank     11G   824K  11.0G        -         -     0%     0%  1.00x  ONLINE  -
root@:~ # zpool status tank
  pool: tank
 state: ONLINE
  scan: none requested
config:


        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada1    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            ada4    ONLINE       0     0     0
            ada5    ONLINE       0     0     0
            ada6    ONLINE       0     0     0

创建了一个名为 tank 的 zpool
这里的 raidz 同 RAID5

除了 raidz 还支持其他方案：

超深度解析

创建 zfs

root@:~ # zfs create -o mountpoint=/mnt/srev tank/srev
root@:~ # df -h tank/srev
Filesystem    Size    Used   Avail Capacity  Mounted on
tank/srev     7.1G    117K    7.1G     0%    /mnt/srev

创建了一个 zfs，挂载到了 /mnt/srev
这里没有指定 zfs 的 quota，创建的 zfs 大小即 zpool 大小

对 zfs 设置 quota

root@:~ # zfs set quota=1G tank/srev
root@:~ # df -h tank/srev
Filesystem    Size    Used   Avail Capacity  Mounted on
tank/srev     1.0G    118K    1.0G     0%    /mnt/srev

ZFS 特性

Pool 存储

上面的层级图和操作步骤可以看到 zfs 是基于 zpool 创建的，zpool 可以动态扩容意味着存储空间也可以动态扩容，而且可以创建多个文件系统，文件系统共享完整的 zpool 空间无需预分配。

事务文件系统

zfs 的写操作是事务的，意味着要么就没写，要么就写成功了，不会像其他文件系统那样，应用打开了文件，写入还没保存的时候断电，导致文件为空。zfs 保证写操作事务采用的是 copy on write 的方式：

超深度解析

ARC 缓存

ZFS 中的 ARC(Adjustable Replacement Cache) 读缓存淘汰算法，是基于 IBM 的 ARP(Adaptive Replacement Cache) 演化而来。在一些文件系统中实现的标准 LRU 算法其实是有缺陷的：比如复制大文件之类的线性大量 I/O 操作，导致缓存失效率猛增（大量文件只读一次，放到内存不会被再读，坐等淘汰）。

另外，缓存可以根据时间来进行优化（LRU，最近最多使用），也可以根据频率进行优化（LFU，最近最常使用），这两种方法各有优劣，但是没办法适应所有场景。

ARC 的设计就是尝试在 LRU 和 LFU 之间找到一个平衡，根据当前的 I/O workload 来调整用 LRU 多一点还是 LFU 多一点。

ARC 定义了 4 个链表：

LRU list：最近最多使用的页面，存具体数据
LFU list：最近最常使用的页面，存具体数据
Ghost list for LRU：最近从 LRU 表淘汰下来的页面信息，不存具体数据，只存页面信息
Ghost list for LFU：最近从 LFU 表淘汰下来的页面信息，不存具体数据，只存页面信息

ARC 工作流程大致如下：

LRU list 和 LFU list 填充和淘汰过程和标准算法一样
当一个页面从 LRU list 淘汰下来时，这个页面的信息会放到 LRU ghost 表中
如果这个页面一直没被再次引用到，那么这个页面的信息最终也会在 LRU ghost 表中被淘汰掉
如果这个页面在 LRU ghost 表中未被淘汰的时候，被再一次访问了，这时候会引起一次幽灵（phantom）命中
phantom 命中的时候，事实上还是要把数据从磁盘第一次放缓存
但是这时候系统知道刚刚被 LRU 表淘汰的页面又被访问到了，说明 LRU list 太小了，这时它会把 LRU list 长度加一，LFU 长度减一
对于 LFU 的过程也与上述过程类似

ZFS 参考资料

关于 ZFS 详细介绍可以参考：

这篇文章

磁盘类型

磁盘根据不同的分类方式，有各种不一样的类型。

磁盘的存储介质

根据磁盘的存储介质可以分两类（大家都很熟悉）：

HDD（机械硬盘）
SSD（固态硬盘）

磁盘的接口

根据磁盘接口分类：

IDE (Integrated Drive Electronics)
SCSI (Small Computer System Interface)
SAS (Serial Attached SCSI)
SATA (Serial ATA)
…

不同的接口，往往分配不同的设备名称。比如， IDE 设备会分配一个 hd 前缀的设备名，SCSI 和 SATA 设备会分配一个 sd 前缀的设备名。如果是多块同类型的磁盘，就会按照 a、b、c 等的字母顺序来编号。

Linux 对磁盘的管理

其实在 Linux 中，磁盘实际上是作为一个块设备来管理的，也就是以块为单位读写数据，并且支持随机读写。每个块设备都会被赋予两个设备号，分别是主、次设备号。主设备号用在驱动程序中，用来区分设备类型；而次设备号则是用来给多个同类设备编号。

g18-"299" on ~# ls -l /dev/sda*
brw-rw---- 1 root disk 8,  0 Apr 25 15:53 /dev/sda
brw-rw---- 1 root disk 8,  1 Apr 25 15:53 /dev/sda1
brw-rw---- 1 root disk 8, 10 Apr 25 15:53 /dev/sda10
brw-rw---- 1 root disk 8,  2 Apr 25 15:53 /dev/sda2
brw-rw---- 1 root disk 8,  5 Apr 25 15:53 /dev/sda5
brw-rw---- 1 root disk 8,  6 Apr 25 15:53 /dev/sda6
brw-rw---- 1 root disk 8,  7 Apr 25 15:53 /dev/sda7
brw-rw---- 1 root disk 8,  8 Apr 25 15:53 /dev/sda8
brw-rw---- 1 root disk 8,  9 Apr 25 15:53 /dev/sda9

这些 sda 磁盘主设备号都是 8，表示它是一个 sd 类型的块设备
次设备号 0-10 表示这些不同 sd 块设备的编号

Generic Block Layer

超深度解析

和 VFS 类似，为了对上层屏蔽不同块设备的差异，内核在文件系统和块设备之前抽象了一个 Generic Block Layer（通用块层），有时候一些人也会把下面的 I/O 调度层并到通用块层里表述。

这两层主要做两件事：

跟 VFS 的功能类似。向上，为文件系统和应用程序，提供访问块设备的标准接口；向下，把各种异构的磁盘设备抽象为统一的块设备，并提供统一框架来管理这些设备的驱动程序
对 I/O 请求进行调度，通过重新排序、合并等方式，提高磁盘读写效率

下图是一个完整的 I/O 栈全景图：

超深度解析

可以看到中间的 Block Layer 其实就是 Generic Block Layer，在图中可以看到 Block Layer 的 I/O 调度分为两类，分别表示单队列和多队列的调度：

I/O scheduler
blkmq

I/O 调度

老版本的内核里只支持单队列的 I/O scheduler，在 3.16 版本的内核开始支持多队列 blkmq，这里介绍几种经典的 I/O 调度策略。

单队列 I/O scheduler：

NOOP：事实上是个 FIFO 的队列，只做基本的请求合并
CFQ：Completely Fair Queueing，完全公平调度器，给每个进程维护一个 I/O 调度队列，按照时间片来均匀分布每个进程 I/O 请求，
DeadLine：为读和写请求创建不同的 I/O 队列，确保达到 deadline 的请求被优先处理

多队列 blkmq：

bfq：Budget Fair Queueing，也是公平调度器，不过不是按时间片来分配，而是按请求的扇区数量（带宽）
kyber：维护两个队列（同步/读、异步/写），同时严格限制发到这两个队列的请求数以保证相应时间
mq-deadline：多队列版本的 deadline
具体各种 I/O 调度策略可以参考 IOSchedulers
关于 blkmq 可以参考 Linux Multi-Queue Block IO Queueing Mechanism (blk-mq) Details
多队列调度可以参考 Block layer introduction part 2: the request layer

性能指标

一般来说 I/O 性能指标有这几个：

使用率：ioutil，指的是磁盘处理 I/O 的时间百分比，ioutil 只看有没有 I/O 请求，不看 I/O 请求的大小。ioutil 越高表示一直都有 I/O 请求，不代表磁盘无法响应新的 I/O 请求
IOPS：每秒的 I/O 请求数
吞吐量/带宽：每秒的 I/O 请求大小，通常是 MB/s 或者 GB/s 为单位
响应时间：I/O 请求发出到收到响应的时间
饱和度：指的是磁盘处理 I/O 的繁忙程度。这个指标比较玄学，没有直接的数据可以表示，一般是根据平均队列请求长度或者响应时间跟基准测试的结果进行对比来估算

（在做基准测试时，还会分顺序/随机、读/写进行排列组合分别去测 IOPS 和带宽）

上面的指标除了饱和度外，其他都可以在监控系统中看到。Linux 也提供了一些命令来输出不同维度的 I/O 状态：