improve restores by posix_fallocate

[ThomasWaldmann]

on POSIX systems, one can tell the filesystem how much data one intends to write into a new file, so it can optimize disk space allocation (and maybe avoid fragmentation when other space allocation on the filesystem happens in parallel).

it's not a very critical thing to have, but if we can simply add it, why not...

see also #252 about posix_fadvise, which is somehow related.

[ThomasWaldmann]

Note: I tried using posix_fallocate for the repo segment writes done by "attic create", but somehow it triggered malfunctions. I guess it is somehow caused by the file append mode and that the file then looks like it is the allocated size big even if you did not yet write any data into it. I tried to solve with seek, but it did not work.

I think it is still worth trying for "attic extract" and files not using append mode.

Here's some more info: http://www.lucas-nussbaum.net/blog/?p=332
"""
The other shortcoming with posix_fallocate() is that it doesn’t support the FALLOC_FL_KEEP_SIZE flag. What this flag allows you to do is to allocate disk blocks to the file, but not to modify the i_size parameter. This allows you to allocate space for files such as log files and mail spool files so they will be contiguous on disk, but since i_size is not modified, programs that append to file won’t get confused, ...
"""

So, it looks like attic would have to stop using append mode for these files to get posix_fallocate working.

[enkore]

See borgbackup/borg#5 (comment)

I'd tick "improve restores by posix_fallocate" because it has next to none positive impact on traditional FSes and (reportedly) negative impact on CoW FSes like ZFS and btrfs

Another very bad thing (tm) about fallocate is that if the FS doesn't support it glibc implements the worst-possible fallback ever.

(both m, cross-media quoting so to speak)