fallocate 是最快的选择，只要文件系统支持（ext4、xfs 等主流格式都支持），1g 文件几乎瞬间完成；它不写数据，仅更新元数据，不触发 i/o 或 cpu 填充，耗时毫秒级，适用于测试挂载、容器卷初始化等场景，但不适用于需真实数据的校验或压测。
fallocate 是最快的选择，只要文件系统支持（ext4、xfs 等主流格式都支持），1G 文件几乎瞬间完成。
fallocate -l 1G 为什么快得离谱
fallocate 不写数据，只更新文件系统元数据，告诉磁盘“这块空间我预占了”。
它不触发实际 I/O，也不消耗 CPU 做填充，所以耗时通常在毫秒级。
- ✅ 适用场景：测试磁盘挂载、容器卷初始化、占位临时文件
- ❌ 不适用场景：需要真实数据内容（比如校验、加密测试、IO 压测）
- ⚠️ 注意：
fallocate在某些旧内核或非标准文件系统（如 overlayfs、某些 NFS 后端）上可能报错Operation not supported
示例：
fallocate -l 1G testfile
验证是否成功：
ls -lh testfile会显示
1.0G；du -h testfile 也显示 1.0G（说明已分配真实块，不是稀疏文件）。
truncate -s 1G 是“假大文件”，慎用
truncate 创建的是稀疏文件（sparse file）：逻辑大小是 1G，但实际不占磁盘空间，直到你往里写数据才逐步分配。
- ✅ 适合：快速占位、测试程序对大文件路径的处理逻辑
- ❌ 不适合：任何依赖实际磁盘占用或 I/O 行为的场景（比如压测、df 容量验证）
- ? 验证方式：
ls -lh testfile显示1.0G，但du -h testfile显示0或极小值
示例：
truncate -s 1G testfile
dd if=/dev/zero 要么慢，要么容易出错
这是最常被抄但最容易踩坑的方法。它真写零，速度取决于磁盘写入性能（机械盘可能几 MB/s，NVMe 盘可达几百 MB/s）。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
常见错误：
-
bs=1M count=1024写 1G —— 正确但慢 -
bs=1G count=1—— 看似聪明，但部分老版本dd对超大bs支持不好，可能失败或卡住 - 忘加
status=progress—— 干等无反馈，以为卡死 - 在只读或空间不足目录下执行 —— 报错后留下不完整文件，需手动清理
推荐写法（平衡兼容性与进度可见）：
dd if=/dev/zero of=testfile bs=4M count=256 status=progress
（4M × 256 = 1024M = 1G）
dd if=/dev/urandom 别乱用在生产环境
生成真随机数据，/dev/urandom 本质是密码学熵池 + PRNG，吞吐低（通常 5–20 MB/s），还可能拖慢系统熵源。
- ✅ 只用于：安全测试、加密算法输入、需要不可预测字节的场景
- ❌ 普通测试完全没必要，纯属自找慢
示例（不推荐日常用）：
dd if=/dev/urandom of=randomfile bs=1M count=1024
真正需要“快速生成 1G 文件”时，先问自己一句：这文件后续要干啥？
如果只是占个大小、跑个路径检查、启动一个容器，fallocate 就够了；
如果下一步就要做 dd 读写压测、校验 md5、或模拟日志追加，那必须用 dd if=/dev/zero 实打实写一遍。
稀疏文件和随机文件的适用边界非常明确，混用会导致测试结果失真——这点最容易被忽略。
