fallocate 生成大文件最快但仅限 ext4/xfs 等支持预分配的文件系统，它通过元数据标记空间而不写数据；dd 更通用但需正确设置 bs 和 count 才高效。
用 fallocate 生成大文件最快，但只适用于 ext4/xfs 等支持预分配的文件系统
fallocate 是内核级操作，不写实际数据，只是在文件系统元数据中标记一段空间为“已分配”，所以几秒就能生成几十 GB 的文件。但它依赖底层文件系统支持：ext4、xfs、btrfs 可以，ext3 和大多数网络/虚拟文件系统（如 NFS、FAT32、NTFS via FUSE）不支持，运行会报错 Operation not supported。
实操建议：
- 确认文件系统类型：
df -T /path/to/dir，看 Type 列是否为ext4或xfs - 生成 10G 空洞文件：
fallocate -l 10G /tmp/testfile - 加
-n参数可跳过空间检查（适合已知磁盘足够时提速），但若磁盘满会导致失败 - 生成后用
ls -lh看大小，du -h看实际占用 —— 两者一致说明是“真实分配”，不是稀疏文件
用 dd 生成大文件更通用，但速度慢、易误配参数
dd 是用户态逐块写入，兼容所有文件系统，但默认行为容易踩坑：不指定 bs 会导致极小块读写（如 512 字节），生成 10G 文件可能耗时数分钟；漏写 count 会让它一直写到磁盘满。
实操建议：
- 必须同时设
bs和count，例如：dd if=/dev/zero of=/tmp/testfile bs=1M count=10240（生成 10G） -
bs=1M比bs=4K快 5–10 倍；超过 8M 后提升不明显，还可能因内存缓冲压力变慢 - 用
if=/dev/urandom会显著变慢（加密随机数生成开销大），测试 I/O 性能时别用它 - 加
status=progress（GNU coreutils ≥8.24）可实时看进度，老系统可用kill -USR1 $(pgrep ^dd)触发状态输出
生成稀疏文件 vs 全零文件：影响后续测试结果
稀疏文件（如 fallocate 默认生成的、或 dd 配合 conv=sparse）在磁盘上不占实际块，但 ls 显示大小正常。一旦你往中间写入数据，文件系统才真正分配磁盘块——这会让 I/O 测试失真，比如测顺序写性能时，前几次写可能快得异常。
实操建议：
- 需要真实占用磁盘空间（比如填满磁盘、压测存储容量），优先用
dd if=/dev/zero of=... bs=1M count=... - 只想快速占位（如预分配日志文件、避免运行时扩容），用
fallocate更稳妥 - 不确定是否稀疏？用
ls -ls对比 “实际磁盘块数 × 512” 和 “显示大小”：差很多就是稀疏文件
注意 fallocate 在某些场景下不等于“清空内容”
fallocate -l 只分配空间，不擦除旧数据。如果覆盖写一个已有文件，原文件的数据块可能还在磁盘上，只是 inode 指针被重定向——这对安全擦除或防止恢复是危险的。
实操建议：
- 敏感数据场景，别用
fallocate覆盖，改用dd if=/dev/zero of=... conv=notrunc清零原有区域 - 容器或 VM 镜像制作中，
fallocate生成的镜像上传后可能被云平台识别为“未初始化”，导致启动慢或 IO 异常 - 脚本中用
fallocate前最好先rm -f目标文件，避免意外复用旧 inode
fallocate 文件根本没触发物理写入 —— 这类误判比命令打错更难排查。
