cp（复制）是否使用fallocate()预先分配空间？

Question

在文件系统之间复制大文件（每个文件 1-2 GB）时，如果目标文件系统几乎已满，则可能会出现文件碎片。

我们的 C++ 应用程序代码fallocate()在创建和写入数据文件时使用预分配空间，但我想知道 linux copy 命令如何/bin/cp处理它。

是否cp只是在循环中复制字节或数据块（并让文件系统处理它）？或者cp首先调用fallocate()orposix_fallocate()与源文件的大小？

我在互联网上搜索没有找到任何关于这个主题的内容。

文件系统可以是 ext3、ext4 或 xfs。

Centos 8.1，内核 4.18.0-147.el8.x86_64 #1 SMP

编辑我

作为背景，实际应用程序读取恒定比特率的网络流并预分配文件 N 秒的内容。如果实际比特率较高，文件自然会增大。ftruncate()文件关闭时调用，它会处理实际比特率是否较低。cp仅用于在文件系统之间移动这些文件，因此是我的问题。

这样做的原因是为了避免碎片化。如果没有fallocate文件系统，随着时间的推移将会变得越来越碎片化。 （当然fallocate()并不能完全防止问题，但肯定会减轻问题）

根据未初始化的块和意外的标志，fallocate()导致连续块的“高效”分配（对于大多数文件系统）：

Fallocate() 系统调用是应用程序请求为文件有效分配块的一种方法。使用fallocate() 允许进程验证所需的磁盘空间是否可用，帮助文件系统在单个连续组中分配所有空间，并避免逐块分配会产生的开销。

所以我想知道复制一个大的、碎片严重的文件最终在目的地是连续的还是碎片的。由于cp不用于fallocate()预先分配空间，那么答案似乎是“可能是”。

Answer 1

cpGNU coreutils 提供的版本确实使用fallocate，但只是在文件中打孔，而不是为复制目标预先分配空间。

有几次提到添加对 的支持fallocate，因此看来在某些时候至少有这样的模糊计划。