On 09/27/18 17:24, Eric Blake wrote: > On 9/26/18 3:35 PM, Laszlo Ersek wrote: >> (+Eric) > >> This too sounds useful. AIUI, ftruncate() is neither forbidden, nor >> required, to allocate filesystem extents when increasing the size of a >> file. Using one smaller regular temporary file as the common foundation >> for multiple "memory-backend-file" objects will save space on the fs if >> ftruncate() happens to allocate extents. > > Correct. Most likely, ftruncate() extends by creating a hole if the file > system supports sparse files, but POSIX has no way to guarantee holes > (it merely states that both ftruncate() and write() beyond EOF are the > two POSIX interfaces that may create holes - but that it is up to the > implementation whether holes actually get created, then fstat() and > lseek(SEEK_HOLE) can inform you whether holes were actually created [the > former when st_blocks < st_size]). posix_fallocate() exists to force > allocation, and Linux fallocate() offers even more fine-tuning when you > need specific hole or non-hole behaviors. >
Thank you for the answers! Laszlo
