C产品如何满足特定用户需求？

本文共计904个文字，预计阅读时间需要4分钟。

默认的FileStream同步写入会卡在磁盘I/O，尤其是小块数据反复写（例如每次+Write 1KB）时。实际上，将SSD/HDD当作日志设备使用，吞吐量可能连理论值的10%都达不到。

• 必须显式启用 FileOptions.WriteThrough 和 FileOptions.NoBuffering（后者要求缓冲区对齐且大小是扇区倍数，通常 4096 字节）才能绕过系统页缓存，测出真实磁盘极限
• 禁用缓存后，Write 调用会真正阻塞到数据落盘，所以要配合 Task.Run 或异步 WriteAsync 避免主线程挂死
• Windows 上 NTFS 默认启用了“最后访问时间更新”，每写一次文件都会触发额外元数据修改，加个 SetFileTime 禁掉能稳提 5–15% 吞吐

并发写多个文件反而更慢？查查 CreateFile 的 dwFlagsAndAttributes

开 8 个线程各自 new FileStream("test_001.dat", FileMode.Create)，结果总吞吐比单线程还低——大概率是 Windows 默认创建文件时加了 FILE_ATTRIBUTE_NORMAL，导致所有句柄竞争同一个 NTFS 元数据锁。

• 改用 FileOptions.DeleteOnClose + 临时目录（如 %TEMP%），绕过重命名和目录索引更新开销
• 如果必须保留文件，至少加上 FileOptions.SequentialScan 告诉内核“我要顺序写”，减少预读干扰
• Linux/macOS 下注意 ext4/xfs 的 chattr +C（写时复制禁用）或 xfs_io -c "extsize 1m" 预分配，否则碎片会快速拖垮随机写性能

Stopwatch 测出来的时间不准？得扣掉 GC.Collect 和内存映射干扰

跑一轮 10GB 写入，Stopwatch.ElapsedMilliseconds 显示 8200ms，但 perfmon 里看到磁盘队列长度峰值 12——说明有大量时间花在等待上，不是纯写入耗时。

• 测试前手动调用 GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, blocking: true)，避免测试中途触发 GC 暂停
• 别用 MemoryMappedFile 测“纯文件系统”，它走的是虚拟内存路径，受 CommitSize 和页面错误影响极大，数据根本没进磁盘栈
• 真要测底层，直接用 DeviceIoControl 发 IOCTL_DISK_PERFORMANCE（需管理员权限），或者用 diskspd 工具交叉验证

为什么 Directory.CreateDirectory 在压力下频繁抛 IOException

不是权限问题，是 NTFS 目录 B+ 树节点分裂时的短暂排他锁。并发建 100 个子目录，失败率可能超 30%，错误信息通常是 "The directory is not empty" 或 "Access is denied"（实际是锁冲突伪装）。

• 提前批量创建好目录结构，用 Directory.EnumerateDirectories 验证存在性，而不是边写边建
• 如果必须动态建，改用 DirectoryInfo.CreateSubdirectory 并捕获 IOException 后退避重试（指数退避，最多 3 次）
• 绕过 .NET 封装，P/Invoke CreateDirectoryW 并传 SECURITY_ATTRIBUTES 避免 ACL 初始化开销

文件系统压力测试真正的难点不在“怎么写快”，而在“怎么让操作系统不偷偷帮你优化、缓存、合并、延迟提交”——一旦漏掉某个标志位或环境配置，测出来的数字就只是内存带宽，不是磁盘能力。