Linux系统中/dev/null设备的写入操作优化程度解析

write请求的内核丢弃位置 #

用户态调用write(2)触发系统调用进入内核后，首先会走通用VFS层的基础处理流程：完成文件访问权限校验、操作合法性检查、参数初步校验后，走到vfs_write的分发逻辑，根据打开文件句柄绑定的file_operations分发给对应设备的实现函数。
/dev/null是内核注册的虚拟字符设备，它的写入回调是null_write，写入请求就在这个字符设备专属的驱动实现层被直接丢弃，不会继续向下进入块IO层、通用硬件驱动层，更不会触达任何物理硬件。null_write的逻辑极其简单，直接返回传入的写入字节数代表写入成功，不发起任何实际IO操作。

写入过程的内存拷贝行为 #

不会发生用户态到内核态的实际数据拷贝。
由于/dev/null不需要处理任何写入的内容，内核根本不会调用copy_from_user类接口把用户态缓冲区的数据搬运到内核内存。整个流程仅会对传入的用户指针、长度参数做最基础的合法性校验（比如确认地址范围属于用户地址空间，避免恶意程序传入非法地址触发内核异常），完全不执行真实的数据搬运操作。

上下文切换相关说明 #

这里需要明确区分两类容易混淆的切换：

• 所有系统调用都会触发CPU特权级切换：调用write(2)时CPU会从用户态（Ring3）切换到内核态（Ring0）执行内核逻辑，执行完成后再切回用户态，这是系统调用的固有流程，不属于通常说的进程上下文切换。
• 不会触发进程上下文切换：整个/dev/null写入路径没有任何阻塞点——不会等待硬件IO、不会等待竞争锁、不会主动调用调度逻辑，全程在当前进程的上下文里快速执行完成后直接返回，调度器不会把当前进程换出、替换为其他进程运行。

writev(2)写入的iovec优化 #

内核针对/dev/null的分散写做了专门优化，不会执行普通文件writev流程里的iovec遍历+逐段数据拷贝逻辑。
对应writev/pwritev入口的write_iter回调实现里，内核不会逐个遍历传入的iovec段、读取每个段的用户地址做数据拷贝，而是直接返回传入的总写入长度代表写入成功。流程中仅保留必要的参数合法性校验，跳过了所有和数据读取、拷贝、iovec遍历相关的冗余操作，实际开销和普通write(2)写/dev/null基本持平。

内容的提问来源于stack exchange，提问作者tsutsu