![cp(复制)是否使用fallocate()预先分配空间?](https://linux22.com/image/13776/cp%EF%BC%88%E5%A4%8D%E5%88%B6%EF%BC%89%E6%98%AF%E5%90%A6%E4%BD%BF%E7%94%A8fallocate()%E9%A2%84%E5%85%88%E5%88%86%E9%85%8D%E7%A9%BA%E9%97%B4%EF%BC%9F.png)
在文件系统之间复制大文件(每个文件 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()
预先分配空间,那么答案似乎是“可能是”。
答案1
cp
GNU coreutils 提供的版本确实使用fallocate
,但只是在文件中打孔,而不是为复制目标预先分配空间。
有几次提到添加对 的支持fallocate
,因此看来在某些时候至少有这样的模糊计划。