磁盘写保护会导致线程在write()调用处无限阻塞而非报错；表现为strace显示write()挂起、CPU占用低、errno未设置，常见于ro挂载、chattr +i文件或硬件写保护设备。
磁盘写保护引发的线程阻塞现象什么样
程序中某个线程突然卡住，write() 或 fwrite() 调用长时间不返回，CPU 占用低，strace 显示系统调用停在 write(3, ...) 上，且该文件描述符对应的是一个只读挂载点或被 chattr +w 锁定的文件。注意：这**不是**权限不足报错（EACCES），而是内核在底层等待 I/O 完成——因为某些写保护机制（如 ext4 的 immutable 属性、NTFS 只读挂载、USB 设备硬件写保护开关）会让内核把写请求挂起而非立即拒绝。
常见诱因包括：
- 目标路径所在分区以
ro选项挂载（mount | grep ro可查） - 文件被设为不可变：
lsattr /path/to/file显示----i--------e-- - 设备本身启用了硬件写保护（如 SD 卡锁扣、某些 USB 闪存盘物理开关）
- 容器或沙箱环境限制了挂载选项（如 Docker 中未加
--read-write）
如何用 strace 快速确认是写保护而非其他 I/O 问题
strace -p <pid> -e trace=write,open,openat,fsync</pid> 是最直接手段。若看到类似：
write(5, "data", 4) = ? EINTR (Interrupted system call)
说明系统调用被中断，可能还在重试；但若持续数秒无输出，且 lsof -p <pid></pid> 显示 fd 5 对应一个只读文件系统中的路径，则基本锁定写保护。
关键判断点：
-
write()不返回-1，也不设errno，只是挂起 → 很可能是底层设备/文件系统阻塞 -
open(O_WRONLY)成功，但后续write()卡住 → 排除权限检查阶段失败，指向写入时的介质级限制 - 同一进程对其他路径（如
/tmp）的写操作正常 → 缩小到特定挂载点或文件属性
C++ 代码里怎么避免线程被永久卡死
不能依赖 write() 自动超时。Linux 默认没有“写超时”机制，尤其对块设备。必须主动控制：
推荐做法：
- 用
O_NONBLOCK打开文件，再配合poll()或epoll()等待可写状态（注意：对普通文件，O_NONBLOCK通常被忽略，但对设备文件/管道有效） - 对确定要写磁盘的场景，改用带超时的同步写法：先
open()，再用write()，若超过阈值（如 2 秒）未返回，close()fd 并报错 - 写前做预检：
statfs()检查f_flag & ST_RDONLY；access(path, W_OK)辅助判断（但注意：它不检测chattr +i） - 关键日志写入建议走
syslog()或通过 socket 发给独立日志服务，绕过本地磁盘依赖
为什么 std::ofstream::write() 看不到错误，但底层已经卡住
std::ofstream 的 write() 是缓冲的，它只负责拷贝进用户态缓冲区，不等内核真正落盘。所以即使磁盘已写保护，write() 调用仍会立刻返回，错误被延迟到 flush()、close() 或缓冲区满自动刷盘时才暴露 —— 这正是容易误判为“程序没出错”的原因。
验证方式：
- 手动调用
ofs.flush()后立刻检查ofs.fail()→ 若此时返回 true，说明刷盘失败 - 关闭前加
ofs.exceptions(std::ios::failbit | std::ios::badbit)，让异常在刷盘失败时抛出 - 不要只检查
ofs.good()，它在缓冲写成功后仍为 true
statfs() 和 lsattr 级别的探测，而不是等到 write() 卡住才开始排查。 
