Improve block file pre-allocation speed on Linux #20113

Is your feature request related to a problem? Please describe.

<!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->

The block file pre-allocation takes too long as currently done by fallocate_posix on Linux (ext4).

Describe the solution you'd like

<!-- A clear and concise description of what you want to happen. -->

There is a way to make it uncomparably faster. I am not yet sure if it is switching to another function for Linux, or just setting some options for the fallocate_posix.

Describe alternatives you've considered

<!-- A clear and concise description of any alternative solutions or features you've considered. -->

I know that file allocation in TransmissionBT torrent client is very fast on Linux. These commits I have identified from searching the logs as related, ordered from newest to oldest: transmission/transmission@a2d56b832, transmission/transmission@99d53d7ef, transmission/transmission@de2d0154e, transmission/transmission@4723b4a6e.

$ man 2 fallocate

https://www.man7.org/linux/man-pages/man2/fallocate.2.html

Additional context

<!-- Add any other context or screenshots about the feature request here. -->

Because I can not work more on it right now, I am dumping what I have found so far into this issue. Feel free to comment or even make a PR. Thank you!

Is pre-allocating files still relevant?

No, I think it is not relevant anymore. Thanks for pointing that out.

From https://manpages.debian.org/buster/manpages-dev/posix_fallocate.3.en.html:

NOTES In the glibc implementation, posix_fallocate() is implemented using the fallocate(2) system call, which is MT-safe. If the underlying filesystem does not support fallocate(2), then the operation is emulated with the following caveats:

• The emulation is inefficient.
• …

While I thought it is still relevant I was about to write all of following:

Currently, glibc provides an interface called posix_fallocate() which can be used for similar cause. Though this has the advantage of working on all file systems, but it is quite slow (since it writes zeroes to each block that has to be preallocated). Without a doubt, file systems can do this more efficiently within the kernel, by implementing the proposed fallocate() system call. It is expected that posix_fallocate() will be modified to call this new system call first and incase the kernel/filesystem does not implement it, it should fall back to the current implementation of writing zeroes to the new blocks.

For more info see https://lwn.net/Articles/239738/ (source of above quote) and upstream commit to glibc

It seems to me that WIN32 and MAC_OSX have an unfair advantage of already using some optimizations in src/util/system.cpp for file allocation, while Linux uses posix_fallocate which works but is clearly not optimal and does not provide a way for filesystem maintainers to offer their own best practices.