五、Request 完整生命周期

5.1 从用户空间到硬件的完整路径

用户进程 write() 系统调用:
│
▼
VFS 层 (vfs_write)
│ → 检查权限、更新文件大小、调用文件系统 write_iter
▼
文件系统层 (ext4/xfs write)
│ → 映射逻辑块到物理块 (ext4_ext_map_blocks)
│ → 创建 bio (submit_bio)
▼
Page Cache (可选)
│ → 检查页面是否存在 (find_get_page)
│ → 不存在则分配新页并标记 (add_to_page_cache)
│ → 脏页回写 (writeback) 时调用 submit_bio
▼
Block Layer (submit_bio)
│ → bio 合法性检查 (bio_check)
│ → 分区偏移调整 (bio_split / bio_chain)
│ → 调用底层 make_request_fn (多队列框架入口)
▼
blk-mq 调度层 (blk_mq_make_request)
│ → 获取硬件队列映射表 (ctx / hctx)
│ → 尝试合并到现有请求 (blk_mq_bio_list_merge)
│ → 创建新 request (blk_mq_get_request)
│ → 放入 I/O 调度器队列 (调度器内部排队)
▼
调度器派发 (__blk_mq_do_dispatch)
│ → 根据调度策略选择下一个请求
│ → 调用 hctx→queue_ops→queue_rq(command)
▼
设备驱动层 (nvme_queue_rq)
│ → 将 request 转换为 NVMe 命令 (nvme_setup_cmd)
│ → 写入 Submission Queue Tail Doorbell
▼
硬件 (NVMe SSD 控制器)
│ → 从 SQ 取出命令并执行
│ → 完成后写入 Completion Queue
▼
中断处理 (MSI-X 中断)
│ → 读取 CQ 完成项
│ → 调用 request_endio → bio_endio
│ → 向上层通知 (页面解锁、唤醒等待进程)
▼
用户进程返回 write()

5.2 关键函数调用链

/* 简化版核心调用链 */

// 1. 提交 bio
void submit_bio(struct bio *bio)
{
    // 走多队列路径
    blk_mq_submit_bio(bio);
}

// 2. blk-mq 入口
void blk_mq_submit_bio(struct bio *bio)
{
    struct blk_mq_hw_ctx *hctx;
    struct request *rq;
    
    // 选择软件队列 (per-cpu 或 numa node)
    hctx = blk_mq_map_queue(q, cpu);
    
    // 尝试合并到已有请求
    if (blk_mq_bio_list_merge(q, hctx, bio_list))
        return;  // 合并成功
    
    // 无法合并，创建新 request
    rq = blk_mq_get_request(q, hctx, bio, nr_vecs);
    
    // 插入调度器队列
    e = ops->insert_requests(hctx, &list, false);
    
    // 如果调度器选择立即派发
    if (e == ELEVATOR_INSERT_SORT_MERGE)
        blk_mq_dispatch_hw_list(hctx);
}

// 3. 驱动层处理
blk_status_t nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
                           const struct blk_mq_queue_data *bd)
{
    struct nvme_command cmd;
    struct request *rq = bd->rq;
    
    // 设置 NVMe 命令
    nvme_setup_cmd(ns, rq);
    
    // 写入 SQ
    nvme_submit_cmd(nvmeq, &cmd);
    
    // 通知硬件 (写 Doorbell)
    writel(nvmeq->sq_tail, nvmeq->q_db);
    
    return BLK_STS_OK;
}

六、性能调优实战

6.1 不同场景的推荐配置

场景1：数据库 (MySQL/PostgreSQL) + NVMe SSD
─────────────────────────────────────────
/sys/block/nvme0n1/queue/scheduler = none   (NVMe 硬件调度足够)
/sys/block/nvme0n1/queue/nr_requests = 1024  (高队列深度)
/sys/block/nvme0n1/queue/read_ahead_kb = 128 (适度预读)
/sys/block/nvme0n1/queue/add_random = 0     (不贡献熵池)
/sys/block/nvme0n1/queue/wbt_lat_usec = 0   (禁用 Write Behind Tracking)

场景2：文件服务器 (NFS/SMB) + HDD RAID
─────────────────────────────────────────
/sys/block/sda/queue/scheduler = mq-deadline
/sys/block/sda/queue/nr_requests = 256
/sys/block/sda/queue/read_ahead_kb = 4096 (大预读)
/sys/block/sda/queue/fifo_batch = 32
/sys/block/sda/queue/read_expire = 200 (快速响应读)

场景3：桌面系统 + SATA SSD
─────────────────────────────────────────
/sys/block/sda/queue/scheduler = bfq
/sys/block/sda/queue/nr_requests = 64
/sys/block/sda/queue/read_ahead_kb = 256

场景4：容器/Kubernetes 节点 + NVMe
─────────────────────────────────────────
/sys/block/nvme0n1/queue/scheduler = kyber
/sys/block/nvme0n1/queue/wbt_lat_usec = (按需启用 Write)
/sys/block/nvme0n1/queue/io_poll = 1 (启用轮询)

6.2 关键可调参数详解

/sys/block//queue/ 核心参数:

调度器选择:
  scheduler = "none mq-deadline bfq kyber"

队列深度:
  nr_requests       - 调度队列深度 (16-4096)
  queue_depth        - 硬件队列深度 (通常只读，由驱动设置，NVMe 默认 1024)

预读策略:
  read_ahead_kb      - 预读页数 (0-4096)
  max_sectors_kb     - 单个请求最大大小

合并策略:
  nomerges           - 禁用合并 (0=允许, 1=仅 front, 2=全部禁用)
  max_segment_size   - 段最大大小
  logical_block_size - 逻辑块大小 (通常 512)

NUMA 亲和性:
  rq_affinity        - request 完成时回原 CPU (2=强制)

加权轮询 (需 BFQ/bfq-iosched):
  wbt_lat_usec       - Write Behind Tracking 延迟目标

6.3 诊断与监控工具

# 查看每个设备的 I/O 统计
cat /sys/block/nvme0n1/stat
# 字段: r_ios r_merges r_sectors r_ticks 
#       w_ios w_merges w_sectors w_ticks
#       in_flight io_ticks time_in_queue

# 使用 iostat 监控
iostat -xz 1
# 关键指标：
#   %util - 设备利用率
#   await - 平均 I/O 等待时间
#   r/s, w/s - 每秒读写次数
#   rkB/s, wkB/s - 吞吐

# blktrace + blkparse 深入分析
blktrace -d /dev/nvme0n1 -o - | blkparse -i -
# 可以看到每个请求的完整生命周期:
# Q (queue) → G (get request) → I (insert) → D (dispatch) → C (complete)

# bpftrace 动态跟踪
bpftrace -e 'kprobe:blk_mq_start_request { @start[arg0] = nsecs; }
            kprobe:blk_mq_end_request { @us = hist((nsecs - @start[arg0]) / 1000); }'

七、高级特性与新技术

7.1 io_uring：新一代异步 I/O 框架

io_uring 旨在彻底取代 AIO，绕过 Block Layer 的瓶颈：

传统同步 write:
  write() → 内核拷贝 → 提交 bio → 等待完成 → 返回
  系统调用开销: ~1-2μs

传统异步 AIO:
  io_submit() → 内核拷贝 → 提交 bio
  io_getevents() → 等待完成
  2 次系统调用，共享队列锁争用

io_uring:
  设置: io_uring_setup() (一次性)
  
  提交: 写 SQE 到共享内存 → 可选 Enter (批量提交)
       无系统调用模式 (IORING_SETUP_SQPOLL)
   
  完成: 从 CQ 读完成事件 (内存映射，零拷贝)
  
  关键优势:
  - 共享内存队列，避免内核拷贝
  - 批处理提交减少系统调用
  - 支持链接 SQE (链式操作)
  - 支持固定文件和缓冲区

io_uring 与 Block Layer 的关系:
- io_uring 通过 fixed buffer 避免 page pin/unpin
- 支持直接 I/O (O_DIRECT)，绕过 page cache
- 仍能使用 Block Layer 的调度器 (除非配置 RING_SETUP_IOPOLL)

7.2 多队列 Block Layer 的调度公平性

问题：blk-mq + 全局 LLD (Logical Disk Driver)
当多个进程同时产生高流量时，某些进程可能独占设备

解决方案1：bgroup (cgroup I/O 权重控制)
  通过 blkio.weight_device 为不同 cgroup 分配权重
  echo "8:0 500" > /sys/fs/cgroup/blkio/blkio.weight_device

解决方案2：写入限流 (Write Throttling)
  当脏页超过阈值 (dirty_ratio) 时，进程被阻塞
  vm.dirty_background_ratio = 10  (后台回写阈值)
  vm.dirty_ratio = 40              (阻塞写入阈值)

解决方案3：Latency Target (kyber/bfq)
  监控请求完成延迟，自动调节队列深度
  当延迟超过目标值时，减少提交速率

7.3 持久内存 (PMem) 与 DAX

传统路径 (通过 block layer):
  read() → page cache → block layer → 设备驱动 → SSD
  延迟: ~100μs

DAX 路径 (绕过 block layer):
  read() → page fault → 文件系统 DAX → 直接 PMEM 访问
  延迟: ~300ns

架构对比:
┌──────────────┐    ┌──────────────┐
│    SSD 路径   │    │   PMem 路径   │
│  VFS          │    │  VFS          │
│  文件系统     │    │  文件系统(ext4/xfs) │
│  Block Layer  │    │  DAX (绕过)    │
│  驱动(nvme)   │    │  nd_pmem      │
│  NVMe SSD     │    │  NVDIMM/Optane│
└──────────────┘    └──────────────┘

八、内核源码级分析

8.1 关键源码文件

Block Layer 核心代码位置:
block/
├── blk-core.c          # Block Layer 核心: request 分配与释放
├── blk-mq.c            # 多队列框架核心实现
├── blk-mq-sched.c      # 调度器集成层
├── blk-mq-tag.c        # 标签分配 (用于避免 request 覆盖)
├── blk-sysfs.c         # sysfs 接口 (queue/* 文件)
├── blk-throttle.c      # I/O 限速 (cgroup 权重)
├── blk-wbt.c           # Write Behind Tracking
├── bfq/                # BFQ 调度器 (独立目录)
│   ├── bfq-iosched.c   # 调度器主体
│   ├── bfq-cgroup.c    # cgroup 权重支持
│   └── bfq.h           # 核心数据结构
├── kyber-iosched.c     # Kyber 调度器
├── mq-deadline.c       # mq-deadline 调度器
└── elevator.c          # 调度器切换接口

请求生成路径:
fs/filemap.c           → submit_bio() 入口
mm/page-writeback.c    → writeback 触发
drivers/nvme/          → NVMe 设备驱动

8.2 bio 处理核心函数

// bio 结构体简化表示
struct bio {
    struct bio          *bi_next;       // 链表下一个 bio
    struct block_device *bi_bdev;       // 关联的块设备
    blk_opf_t           bi_opf;         // 操作类型 (READ/WRITE/FLUSH/DISCARD)
    unsigned short      bi_vcnt;        // bio_vec 数量
    unsigned short      bi_max_vecs;    // 最大 vec 数量
    unsigned short      bi_flags;       // 状态标志
    struct bvec_iter    bi_iter;        // 当前扇区位置
    bio_end_io_t        *bi_end_io;     // 完成回调函数
    void                *bi_private;    // 私有数据
    struct bio_vec      bi_io_vec[0];   // page 数组的柔性数组
};

// bio_vec 代表一个 page 片段
struct bio_vec {
    struct page *bv_page;       // 关联的物理页
    unsigned int bv_len;        // 字节长度
    unsigned int bv_offset;     // 页内偏移
};

九、常见陷阱与最佳实践

9.1 写放大的隐形杀手

问题描述:
SSD 的最小写入单元是 page (通常 4KB-16KB)，擦除单元是 block (128-256 pages)
如果小块随机写入过多 → GC 触发 → 写放大系数飙升

观测指标:
iostat -x 中 %util 高但 throughput 低 → 可能 GC 影响
smartctl -a /dev/nvme0n1 | grep "Percentage Used"

缓解策略:
1. 使用更大的文件系统块大小 (mkfs.ext4 -b 4096)
2. 启用 TRIM/Discard (mount -o discard)
3. 对齐分区到 1MB 边界 (fdisk -H 224 -S 56)
4. 预留足够的 OP (Over-Provisioning) 空间

9.2 误用 nomerges 的灾难

场景: 高吞吐视频流写入
误调: echo 2 > /sys/block/sda/queue/nomerges
结果: 原本可以合并的 1000 个 4K 小写变成一个 4M 大写的场景
      变成 1000 个独立小写 → HDD 寻道成本爆炸 → 吞吐下降 80%

正确理解:
nomerges=0: 允许所有合并 (默认)
nomerges=1: 仅禁止前端合并 (保留后端合并)
nomerges=2: 完全禁止合并 (仅特定高性能 NVMe 场景使用)

9.3 容器场景的 I/O 隔离缺失

问题: 容器中的邻居嘈杂 (Noisy Neighbor) 效应
容器 A 疯狂写入 → 容器 B 的数据库读延迟增加 10 倍

原因: Docker/K8s 默认不隔离块设备 I/O 资源

解决方案1: BFQ + cgroup v2
  设置容器 I/O 权重:
  echo "8:0 riops=1000 wiops=500" > io.max

解决方案2: iotop 定位
  iotop -oP 找出占用 I/O 最高的容器/PID

解决方案3: ionice 优先级调整
  ionice -c2 -n0 -p   (实时级, 最高优先级)
  ionice -c3 -p       (空闲级, 仅空闲时调度)

9.4 生产环境调优检查清单

✅ 硬件层面
  ├── SSD firmware 已更新
  ├── 分区已对齐 (parted align=optimal)
  ├── APST (Autonomous Power State Transition) 已正确配置
  └── 写入寿命 (TBW/DWPD) 满足需求

✅ 内核参数层面
  ├── 调度器匹配设备类型 (none/mq-deadline/bfq/kyber)
  ├── queue/nr_requests 匹配负载特征
  ├── read_ahead_kb 匹配应用场景
  ├── vm.dirty_* 比值合理 (通常 background=10, ratio=40)
  └── io_poll 按需启用 (仅延迟极度敏感场景)

✅ 文件系统层面
  ├── 块大小匹配工作负载 (数据库用 4K, 大文件用更大)
  ├── 启用适合的文件系统功能 (ext4 journal、xfs reflink)
  ├── 考虑 noatime/nodiratime 或 relatime
  └── 启用 TRIM (discard 或 fstrim 定时)

✅ 监控层面
  ├── iostat 持续监控 await/avgqu-sz/%util
  ├── blktrace 用于偶尔的深入分析
  ├── SMART 健康度定期检查
  └── 写放大系数观测 (SSD 特有)

十、发展趋势与展望

Linux Block Layer 正经历着从单队列到多队列、从同步到异步、从磁盘到持久内存的持续演进。io_uring 的出现大幅减少了系统调用开销，SPDK 和用户态驱动技术进一步优化了直通路径。随着 CXL (Compute Express Link) 内存的普及，Block Layer 可能会提供更灵活的 "存储层级" 支持，将 NVMe SSD 和 CXL-attached memory 统一在相同的请求分发框架之下。

对于系统工程师而言，理解 Block Layer 的工作原理可以帮助你在以下场景做出正确的决策：为什么数据库服务器应该用 none 调度器而不是 mq-deadline，为什么容器的 BFQ 权重可以解决 "邻居嘈杂" 问题，以及为什么 io_uring 能够比传统方式减少 30-50% 的 I/O 延迟。

Linux内核系列将继续深入更多子系统的内部原理。