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）。
常见错误：
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实实在在地写一遍。
稀疏文件和随机文件的适用范围很明确，用错了可会让测试结果不准——这一点最容易被忽视。
