cp（複製）是否使用 fallocate() 預先分配空間？
在文件系統之間複製大文件（每個文件 1-2 GB）時，如果目標文件系統快滿了，可能會發生文件碎片。
我們的 C++ 應用程式碼
fallocate()在創建和寫入數據文件時用於預分配空間，但我想知道 linux 複製命令如何/bin/cp處理這個問題。是否
cp只是在循環中復製字節或數據塊（並讓文件系統處理它）？還是cp先呼叫fallocate()還是posix_fallocate()用源文件的大小？我在網際網路上沒有找到關於這個主題的任何內容。
文件系統可以是 ext3、ext4 或 xfs。
Centos 8.1，核心 4.18.0-147.el8.x86_64 #1 SMP
編輯我
作為背景，實際應用程序讀取一個恆定比特率的網路流，並為 N 秒的內容預先分配一個文件。如果實際比特率更高，文件自然會增長。
ftruncate()當文件關閉時呼叫，如果實際比特率較低，它會處理。cp僅用於在文件系統之間移動這些文件，因此我的問題。這樣做的原因是為了避免碎片化。沒有
fallocate文件系統會隨著時間的推移變得越來越碎片化。（當然fallocate()不能完全防止問題，但肯定會減輕它）根據Uninitialized blocks and unexpected flags，
fallocate()導致連續塊的“有效”分配（對於大多數文件系統）：fallocate() 系統呼叫是應用程序為文件請求有效分配塊的一種方式。使用 fallocate() 允許程序驗證所需的磁碟空間是否可用，幫助文件系統在單個連續組中分配所有空間，並避免逐塊分配會產生的成本。
所以我想知道複製一個大的、碎片嚴重的文件是否最終會在目的地連續或碎片化。由於
cp不fallocate()用於預先分配空間，因此答案似乎是“可能是”。
cpGNU coreutils 提供的版本確實使用fallocate，但僅用於在文件中打孔，而不是為複制目標預先分配空間。有幾處提到添加對
fallocate.