输入输出系统实战：字符设备、块设备与一切皆文件——公司的售前售后体系

输入输出系统实战：字符设备、块设备与一切皆文件——公司的售前售后体系

本文是《趣谈 Linux 操作系统》风格的实战续篇，与上篇《进程间通信实战》配套。所有命令与输出均来自一台真实云服务器（华为云 FlexusX，Ubuntu 24.04，内核 6.8.0），无一字虚构。建议边读边在自己的机器上复现。

引子：把 IO 系统想成公司的"售前售后体系"

公司要对外做生意，得有售前（接需求、收材料）和售后（发货、维护）。在 Linux 里，所有硬件、所有能"读写"的东西，都被抽象成一个统一的对象——文件。这就是著名的 “一切皆文件”（Everything is a File）。

• 文件（包括普通文件、设备、管道、socket）= 公司的对外窗口，统一用open/read/write/close这套界面办事。
• VFS（虚拟文件系统）= 公司总机的统一话术，不管你找的是硬盘、键盘还是网卡，前台都给你同一套"受理/交接"流程。
• 字符设备（Character Device）=售前窗口：像键盘、鼠标、串口，数据是一个个字符流式来的，不能随机跳着读。
• 块设备（Block Device）=售后仓库：像硬盘，数据按**固定大小的块（512B/4KB）**存取，支持随机寻址、缓存、批量发货。
• 设备文件/dev/xxx= 窗口的门牌号，背后挂着"主设备号+次设备号"，内核靠它找到对应的"部门"（驱动）。
• 设备驱动= 具体干活的业务部门，窗口接到请求就转给驱动去操作硬件。
• sysfs / udev= 公司的内部通讯录与自动排号机，内核把设备树暴露给用户空间，udev 按规则自动在/dev下生成/命名窗口。
• ioctl= "窗口"之外那些特殊业务（查窗口尺寸、问仓库容量），走专门的"密语"通道。
• epoll= 售后部一对多的高效接线员，谁有活儿了才叫谁，不用挨个打电话问。

下面用一台真机，把这套"对外体系"从门牌号到接线员全拆一遍。

实验环境

实验一：一切皆文件——先认门牌号

1.1 看看 /dev 下都挂了哪些"窗口"

ls-l/dev|head-30

真实输出（节选）：

total 0 crw-r--r-- 1 root root 10, 235 Jul 29 12:49 autofs drwxr-xr-x 2 root root 240 Jul 29 12:49 block crw-rw---- 1 root disk 10, 234 Jul 29 12:49 btrfs-control drwxr-xr-x 3 root root 60 Jul 29 12:49 bus drwxr-xr-x 2 root root 3500 Jul 29 12:49 char crw------- 1 root root 5, 1 Jul 29 12:49 console lrwxrwxrwx 1 root root 11 Jul 29 12:49 core -> /proc/kcore drwxr-xr-x 10 root root 200 Jul 29 12:49 cpu crw------- 1 root root 1, 7 Jul 29 12:49 full crw-rw-rw- 1 root root 10, 229 Jul 29 12:49 fuse crw------- 1 root root 240, 0 Jul 29 12:49 hidraw0 brw-rw---- 1 root disk 7, 0 Jul 29 12:49 loop0 brw-rw---- 1 root disk 7, 1 Jul 29 12:49 loop1

两个最该记住的"类型位"：

• c= 字符设备（character），如console、fuse、hidraw0。
• b= 块设备（block），如loop0、loop1。
• 行尾那两个数字，比如10, 235、7, 0，就是主设备号, 次设备号：主号告诉内核"用哪个驱动部门"，次号区分"同部门下的第几个窗口"。

1.2 只看字符设备和块设备

ls-l/dev|grep-E"^(c|b)"|head-12

真实输出：

crw-r--r-- 1 root root 10, 235 Jul 29 12:49 autofs crw-rw---- 1 root disk 10, 234 Jul 29 12:49 btrfs-control crw------- 1 root root 5, 1 Jul 29 12:49 console crw-rw-rw- 1 root root 1, 7 Jul 29 12:49 full crw-rw-rw- 1 root root 10, 229 Jul 29 12:49 fuse crw------- 1 root root 240, 0 Jul 29 12:49 hidraw0 crw------- 1 root root 10, 228 Jul 29 12:49 hpet brw-rw---- 1 root disk 7, 0 Jul 29 12:49 loop0 brw-rw---- 1 root disk 7, 1 Jul 29 12:49 loop1

1.3 内核眼里的设备"部门列表"：/proc/devices

/dev下是文件节点，而/proc/devices列出当前内核注册了哪些字符设备类、哪些块设备类：

head-25/proc/devices

真实输出：

Character devices: 1 mem 4 /dev/vc/0 4 tty 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 21 sg 29 fb 89 i2c 108 ppp 128 ptm 136 pts 180 usb 189 usb_device 202 cpu/msr 204 ttyMAX 226 drm 240 hidraw

左侧数字就是主设备号，右侧是部门名（mem、tty、input、usb、hidraw…）。open("/dev/tty")时，内核查到它主设备号 5，就交给"tty 部门"的驱动去处理。

实验二：字符设备——售前窗口们的脾气

2.1 /dev/zero：永不枯竭的"0"泉

读它，得到无限多的\0；常用来造文件或当占位数据源：

ddif=/dev/zeroof=/tmp/zero.binbs=1Mcount=50ls-l/tmp/zero.bin|awk"{print \$5}"

真实输出：

50+0 records out 52428800 bytes (52 MB, 50 MiB) copied, 0.0339447 s, 1.5 GB/s 52428800

50 MB 全是 0，写入速度 1.5 GB/s——数据来自内核直接填零，不真读硬件。

2.2 /dev/null：写进去就消失的碎纸机

往它写什么都"丢弃"，常用来屏蔽不需要的输出：

ddif=/dev/urandomof=/dev/nullbs=1Mcount=1002>&1|tail-1

真实输出：

104857600 bytes (105 MB, 100 MiB) copied, 0.238128 s, 440 MB/s

100 MB 随机数写进"黑洞"约 440 MB/s（瓶颈在/dev/urandom产随机数的速度）。

2.3 /dev/random vs /dev/urandom：随机数兄弟

很多人以为/dev/random更安全所以更慢、还会"阻塞"。在 5.6 之后的内核（我们这是 6.8）这已经过时了：两者底层都是同一个 CSPRNG（密码学安全伪随机数生成器），/dev/random不再因"熵池不足"而阻塞。跑一下对比：

echo"[urandom]";ddif=/dev/urandomof=/dev/nullbs=1Mcount=82>&1|tail-1echo"[random ]";timeout5ddif=/dev/randomof=/dev/nullbs=1Mcount=82>&1|tail-1

真实输出：

[urandom] 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0194582 s, 431 MB/s [random ] 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0194179 s, 432 MB/s

两者 8 MB 都在 ~0.019 s、约 431~432 MB/s，完全一致——正是内核 5.6+ 把/dev/random改成"非阻塞、与 urandom 同源"的直接证据。

2.4 /dev/tty：当前控制终端

往/dev/tty写，内容会显示在进程的控制终端上。但在非交互的远程执行里，没有控制终端：

ttyecho"hello-from-dev-tty">/dev/tty2>&1&&echo"(已写入当前控制终端)"||echo"(非交互终端, /dev/tty 不可写, 属正常现象)"

真实输出：

not a tty (非交互终端, /dev/tty 不可写, 属正常现象)

这是预期之内：脚本跑在没有终端的环境，/dev/tty没有"对讲机"可连。

实验三：块设备——售后仓库的货架与调度

3.1 lsblk -f：仓库与货架总览

lsblk-f

真实输出：

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS vda └─vda1 ext4 1.0 35f7b939-7473-4e43-8527-a2f647b4c6a2 34.3G 8% /

一块虚拟磁盘vda，上面一个分区vda1，格式化为 ext4，挂在根/，还剩 34.3 G、用了 8%。

3.2 fdisk -l：仓库的建筑图纸

fdisk-l2>/dev/null|head-20

真实输出：

Disk /dev/vda: 40 GiB, 42949672960 bytes, 83886080 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x87ac7989 Device Boot Start End Sectors Size Id Type /dev/vda1 * 2048 83886046 83883999 40G 83 Linux

磁盘 40 GiB、共 83886080 个扇区、每扇区 512 字节；vda1从第 2048 扇区起到结尾，约 40 G，类型 Linux(83)。

3.3 块大小：逻辑块 vs 物理扇区

echo-n"vda : ";blockdev--getbsz/dev/vdaecho-n"vda1 : ";blockdev--getbsz/dev/vda1echo-n"物理扇区: ";blockdev--getpbsz/dev/vda

真实输出：

vda : 4096 vda1 : 4096 物理扇区: 512

逻辑块大小（文件系统打交道的最小单位）是4096 字节，而物理扇区是512 字节。文件系统以 4 KB 为一块读写，落到磁盘上由驱动/阵列再拆成 512 B 的扇区。

3.4 IO 调度器：仓库发货的排队策略

echo-n"当前调度器: ";cat/sys/block/vda/queue/schedulerecho-n"只读/旋转: ";cat/sys/block/vda/queue/rotational

真实输出：

当前调度器: [none] mq-deadline 只读/旋转: 1

注意当前选中的是[none]。none就是"noop/透传"——对 virtio 这类飞快的虚拟磁盘，真实的排队调度在宿主机那一侧做，虚拟机里再排一遍纯属多余，所以内核直接选了none（mq-deadline 作为备选保留着）。rotational=1表示内核认为它是"机械盘"（虚拟设备上报的默认值，实际是 SSD 般的虚拟盘）。

实验四：IO 调度与性能观察——接线员怎么排活

iostat（来自 sysstat）是看磁盘忙不忙的标配。我们先用空闲基线看看输出长啥样，再验证一次真实写入确实落盘。

4.1 空闲基线 iostat -x 1 3

iostat-x13

真实输出（节选第三段，已接近空闲）：

Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util vda 0.00 0.00 0.00 0.00 0.00 0.00 4.00 48.00 8.00 66.67 0.75 12.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 0.20

几个核心列的含义：

• r/s, w/s：每秒读/写请求数。
• rkB/s, wkB/s：每秒读/写的数据量（KB）。
• r_await, w_await：读/写请求的平均等待时间（毫秒），含排队 + 硬件处理，越短越好。
• aqu-sz：平均队列长度（积压的请求数）。
• %util：设备Busy 时间占比，接近 100% 说明仓库快被压满了。

（第一段采样里这台机还有些后台活儿：vda 有 r/s 7.28、rkB/s 347、w/s 9.18、%util 0.96；到第三段已归于平静。）

4.2 写压力下的真实统计（用 /proc/diskstats 差值）

iostat的数据其实就来自/proc/diskstats。我们写 300 MB 到磁盘，再算写前后的差值，亲手验证"数据真的落盘了"：

echo"BEFORE:";awk"/vda1/{print}"/proc/diskstatsddif=/dev/zeroof=/root/io/bigfilebs=1Mcount=300conv=fdatasync# 强制落盘echo"AFTER :";awk"/vda1/{print}"/proc/diskstatsrm-f/root/io/bigfile

真实输出（已对齐字段）：

BEFORE: 253 1 vda1 12328 3428 1184245 31051 18095 8255 5208224 563260 0 23097 594311 ... AFTER : 253 1 vda1 12328 3428 1184245 31051 18534 8268 5822744 680587 0 24714 711638 ... # 计算差值(写相关字段): # write I/O 次数: 18534 - 18095 = 439 # write 扇区数 : 5822744 - 5208224 = 614520 扇区 × 512 = 314,634,240 字节 ≈ 300 MB

差值里write 扇区增量 = 614520 扇区 ≈ 300 MB，与dd写的 300 MiB 严丝合缝——证明这笔写确实走到了vda1。

实战提示：在写压力下，你用iostat -x 1会看到vda的w/s、wkB/s、w_await、%util明显爬升；上面这组/proc/diskstats差值就是 iostat 背后读取并做差的那份"原始账本"。生产排障时，盯w_await突增和%util长期 100% 往往就是磁盘瓶颈信号。

实验五：Buffered IO vs Direct IO——要不要走"阅览室"

文件读写默认走Page Cache（页缓存，就是前面说的"阅览室"）；也可以O_DIRECT绕过缓存、直写磁盘。两者差距有多大？

echo"[Buffered] 默认写(page cache):"ddif=/dev/zeroof=/tmp/buf.binbs=1Mcount=2002>&1|tail-1echo"[Direct ] oflag=direct(绕过page cache, 直接写盘):"ddif=/dev/zeroof=/tmp/direct.binbs=1Mcount=200oflag=direct2>&1|tail-1rm-f/tmp/buf.bin /tmp/direct.bin

真实输出：

[Buffered] 默认写(page cache): 209715200 bytes (210 MB, 200 MiB) copied, 0.127169 s, 1.6 GB/s [Direct ] oflag=direct(绕过page cache, 直接写盘): 209715200 bytes (210 MB, 200 MiB) copied, 1.86578 s, 112 MB/s

差距非常直观：Buffered IO 1.6 GB/s，Direct IO 只有 112 MB/s。

• Buffered IO：数据先写进内存里的页缓存，立刻返回（"看起来"飞快），真正刷盘由内核的回写线程pdflush异步完成。好处是多次小写给合并、读可命中缓存。
• Direct IO：绕过页缓存，每次写都直达块设备，速度被磁盘物理带宽卡死（这台虚拟盘约 100~200 MB/s）。但它避免了"缓存污染"和"双份拷贝"，数据库（如 MySQL InnoDB）自己做缓存层时偏爱 Direct IO，省掉一层内核缓存。

注意：Direct IO 要求内存地址、长度、偏移都对齐到块大小（本例bs=1M天然对齐），否则会报EINVAL。

实验六：设备驱动与 sysfs——内部通讯录

6.1 /sys/class：按"设备类别"排的通讯录

/sys/class/把设备按类组织，每类下是具体设备：

ls/sys/class/|head-30

真实输出：

accel ata_device ata_link ata_port backlight bdi block bsg devcoredump devfreq devfreq-event devlink dma dma_heap dmi drm extcon firmware gpio graphics hidraw hwmon i2c-adapter i2c-dev input intel_scu_ipc iommu leds mdio_bus mem

block/、input/、mem/、graphics/……就是内核暴露给用户空间的"设备分类树"。

6.2 udevadm：查这个窗口的"档案"

udev负责在/dev下按规则自动生成、命名设备节点。用udevadm info看/dev/vda的来龙去脉：

udevadm info--query=all--name=/dev/vda2>/dev/null|head-15

真实输出：

P: /devices/pci0000:00/0000:00:07.0/0000:02:01.0/virtio5/block/vda M: vda U: block T: disk D: b 253:0 N: vda L: 0 S: disk/by-path/virtio-pci-0000:02:01.0 S: disk/by-id/virtio-73fb188a-a225-46cd-8 S: disk/by-dname/main_disk S: disk/by-path/pci-0000:02:01.0 S: disk/by-diskseq/9 Q: 9 E: DEVPATH=/devices/pci0000:00/0000:00:07.0/0000:02:01.0/virtio5/block/vda E: DEVNAME=/dev/vda

这告诉我们：/dev/vda的内核设备路径（DEVPATH）是一条 PCI→virtio→block 的总线树；它的主:次设备号是b 253:0；udev 还顺手建了几个软链接别名（/dev/disk/by-id/...、/dev/disk/by-path/...、/dev/disk/by-dname/main_disk），这就是为什么你在/etc/fstab里用/dev/disk/by-uuid/...比直接用/dev/vda1更稳——盘符可能会变，UUID 不会。

实验七：ioctl——窗口之外的"密语"通道

很多操作不适合走read/write这种"流式"界面，比如"问终端多大"、“问磁盘多大”。这类特殊查询走ioctl（I/O control），一个万能的"控制面"系统调用。

下面程序干了两件实事：用BLKGETSIZE64问块设备容量，用TIOCGWINSZ问终端窗口大小。

#include<stdio.h>#include<fcntl.h>#include<unistd.h>#include<sys/ioctl.h>#include<linux/fs.h>#include<termios.h>intmain(){intfd=open("/dev/vda1",O_RDONLY);unsignedlonglongsize=0;if(ioctl(fd,BLKGETSIZE64,&size)==0)printf("BLKGETSIZE64 /dev/vda1 = %llu 字节 (%.2f GB)\n",size,size/1024.0/1024/1024);else{perror("BLKGETSIZE64");}close(fd);structwinsizews;if(ioctl(STDOUT_FILENO,TIOCGWINSZ,&ws)==0)printf("TIOCGWINSZ 终端窗口: 行=%d 列=%d\n",ws.ws_row,ws.ws_col);elseprintf("TIOCGWINSZ: 当前 stdout 不是 tty, 无法获取窗口大小(属正常现象)\n");return0;}

编译运行：

gcc-O2-oioctl_demo ioctl_demo.c&&./ioctl_demo

真实输出：

BLKGETSIZE64 /dev/vda1 = 42948607488 字节 (40.00 GB) TIOCGWINSZ: 当前 stdout 不是 tty, 无法获取窗口大小(属正常现象)

BLKGETSIZE64直接问出vda1是40.00 GB——和fdisk看到的 40 G 对上了。TIOCGWINSZ在非交互环境拿不到窗口大小，属正常（和前面/dev/tty一样的道理）。ioctl 的第二个参数就是"密语代号"，不同设备认不同的代号，驱动里switch(cmd)分发处理。

实验八：epoll vs select——高效接线员

当进程要同时盯着多个文件/连接（比如一个网络服务器守着上千个 socket），怎么知道"谁有数据可读了"？

• select / poll：每次调用都把"我要监视的 fd 集合"从用户态拷进内核，内核挨个遍历所有 fd 看谁就绪，复杂度 O(n)。fd 一多就慢。
• epoll（Linux 专属）：注册一次（内核用红黑树存兴趣列表），之后epoll_wait只返回"就绪队列"里的 fd，复杂度O(1)，且支持边缘触发（ET）。

下面用 epoll 盯着一根管道，等对方写数据：

#include<stdio.h>#include<stdlib.h>#include<unistd.h>#include<sys/epoll.h>#include<string.h>#include<sys/wait.h>intmain(){intfd[2];pipe(fd);intep=epoll_create1(0);structepoll_eventev,events[1];ev.events=EPOLLIN;ev.data.fd=fd[0];epoll_ctl(ep,EPOLL_CTL_ADD,fd[0],&ev);pid_tpid=fork();if(pid==0){close(fd[0]);sleep(1);write(fd[1],"hello-epoll",12);close(fd[1]);exit(0);}else{close(fd[1]);printf("epoll_wait 等待管道可读(超时5s)...\n");intn=epoll_wait(ep,events,1,5000);if(n>0){charbuf[64];ssize_tr=read(events[0].data.fd,buf,sizeof(buf)-1);buf[r]=0;printf("epoll 报告 %d 个就绪事件, 读到: %s\n",n,buf);}else{printf("epoll_wait 返回 %d (超时或出错)\n",n);}wait(NULL);close(fd[0]);close(ep);}return0;}

编译运行：

gcc-O2-oepoll_demo epoll_demo.c&&./epoll_demo

真实输出：

epoll_wait 等待管道可读(超时5s)... epoll 报告 1 个就绪事件, 读到: hello-epoll

子进程 1 秒后往管道写 “hello-epoll”，父进程没用忙等、也没用"遍历所有 fd"，而是被 epoll精准通知"你盯的那根管道现在可读了"，一次epoll_wait就拿到就绪事件并读出了数据。这就是高并发服务器（Nginx、Redis）用 epoll 扛住百万连接的根本原因。

原理图：一切皆文件的调用链路

用户进程 内核空间 硬件 ┌──────┐ │ open │── 路径 "/dev/vda1" ──► VFS 统一入口 └──────┘ │ ┌──────┐ │ 按 主/次设备号 查表 │ read │── 文件描述符 fd ──────► │ │write │ ▼ └──────┘ ┌──────────┐ ┌──────────────┐ │ 字符设备 │ │ 块设备驱动 │──► 磁盘/网卡 │ 驱动 │ │ (请求→bio→ │ │(流式逐字节)│ │ IO调度队列) │ └──────────┘ └──────────────┘ ioctl ─► "控制面" 密语 ──► 驱动 switch(cmd) epoll ─► 就绪事件通知 ──► 内核事件表(红黑树)+就绪队列 /dev/xxx (门牌) ──udev──► 由 sysfs 设备树 自动生成

总结

一句话记忆：/dev是门牌，主/次设备号是指路牌，字符设备管流式售前、块设备管块状售后，sysfs/udev 是自动通讯录，ioctl 是密语通道，epoll 是能同时盯上千个窗口的金牌接线员。"一切皆文件"不是一句口号，而是让上层的 open/read/write 不必关心对面是硬盘、键盘还是网卡的统一契约。

思考题

1. 为什么/dev/random在老教程里"会阻塞"，而我们的 6.8 内核里和/dev/urandom一样快？（提示：内核 5.6 的改动）
2. iostat的%util达到 100% 一定代表磁盘"到顶"了吗？如果是 NVMe 这种能并行很多请求的设备，这个结论还成立吗？
3. 试试用strace dd if=/dev/zero of=/tmp/x bs=1M count=10 oflag=direct跟踪，你能看到open(..., O_DIRECT)和fsync吗？
4. epoll 的"边缘触发(ET)"和"水平触发(LT)"有什么区别？为什么 ET 模式要求配合非阻塞 fd + 循环读？
5. 既然"一切皆文件"，那网络 socket 算文件吗？ls -l /proc/<pid>/fd里 socket 类型的 fd 长什么样？

实验环境：华为云 FlexusX ecs-44ec-0003，Ubuntu 24.04，内核 6.8.0-106-generic。所有命令与输出均在该真机上执行，无虚构。上一篇《进程间通信实战》见05-进程间通信实战.md。