fallocate与ftruncate的区别：为何两者均可修改文件大小？

嘿，这个问题问到点子上了！我在日常运维和开发中经常和这两个工具打交道，它们虽然都能调整文件大小，但背后的逻辑和适用场景差得挺远，给你拆解清楚：

1. 磁盘空间分配逻辑：预分配 vs 按需分配 #

这是两者最本质的区别：

• fallocate：主打快速预分配磁盘空间。它直接跟文件系统打个招呼：“我要占这么多字节的位置”，文件系统会立刻把对应数量的磁盘扇区标记为已使用，但不会往里面写任何数据（除非你加-z参数强制清零）。整个过程几乎是瞬间完成的，哪怕是创建几十GB的大文件也一样。
• ftruncate：它只修改文件的逻辑大小。如果是扩大文件，默认不会提前占磁盘空间——只有当你后续往那些新扩展的区域写入数据时，文件系统才会逐个分配磁盘块。缩小文件时，两者都会释放超出部分的空间，但ftruncate是从文件末尾直接截断。

2. 扩展区域的内容处理 #

当你把文件扩大时，新区域的内容差异很大：

• fallocate（默认）：新扩展的区域是未初始化的磁盘残留数据，直接读的话会拿到磁盘上原来的脏数据。如果用fallocate -z filename -l size，会把新区域清零，但这时候速度会变慢，因为要实际写入数据了。
• ftruncate：新扩展的区域会被视为全零内容，哪怕磁盘上没分配空间，读这些位置也会返回0。这就是我们常说的“稀疏文件”特性。

3. 适用场景大不同 #

• 选fallocate的情况：
  • 需要快速创建大文件（比如虚拟机镜像、大型日志文件），避免后续写入时因为磁盘空间不足报错；
  • 不想用稀疏文件，担心碎片化或者需要确保磁盘空间确实被预留。
• 选ftruncate的情况：
  • 想要创建稀疏文件节省磁盘空间（比如某些数据库的临时文件、备份文件）；
  • 跨平台场景，需要兼容Linux以外的类Unix系统（比如macOS、BSD）；
  • 只是简单调整文件大小，不关心预分配的细节。

4. 兼容性差异 #

• fallocate是Linux专属的工具（对应系统调用fallocate()），而且需要文件系统支持（比如ext4、XFS都支持，但FAT、某些老旧文件系统不支持）；
• ftruncate是POSIX标准的系统调用，几乎所有类Unix系统都支持，兼容性拉满。

举个直观的例子：

要创建一个10GB的文件，用fallocate -l 10G test.img，几毫秒就完成，而且你的磁盘会立刻少10GB空间；用truncate -s 10G test.img（命令行工具对应ftruncate系统调用），文件逻辑大小是10GB，但实际磁盘占用可能只有几KB，直到你往里面写数据才会逐步占用空间。

内容的提问来源于stack exchange，提问作者Lenge