[all-commits] [llvm/llvm-project] 98e0b2: [Support] Revert posix_fallocate in resize_file

Fangrui Song via All-commits all-commits at lists.llvm.org
Mon Dec 20 11:16:16 PST 2021

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 98e0b2cf700191558268728f2a8e65dfe13bf0da
  Author: Fangrui Song <i at maskray.me>
  Date:   2021-12-20 (Mon, 20 Dec 2021)

  Changed paths:
    M llvm/cmake/config-ix.cmake
    M llvm/include/llvm/Config/config.h.cmake
    M llvm/lib/Support/Unix/Path.inc
    M llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
    M utils/bazel/llvm-project-overlay/llvm/config.bzl
    M utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/config.h
    M utils/bazel/llvm_configs/config.h.cmake

  Log Message:
  [Support] Revert posix_fallocate in resize_file

This reverts 3816c53f040cc6aa06425978dd504b0bd5b7899c and removes follow-up

The original intention was to show error earlier (posix_fallocate time) than
later for ld.lld but it appears to cause some problems which make it not free.

* FreeBSD ZFS: EINVAL, not too bad.
* FreeBSD UFS: according to khng "devastatingly slow on freebsd because UFS on freebsd does not have preallocation support like illumos. It zero-fills."
* Linux tmpfs: unless tmpfs is set up to use huge pages (requires CONFIG_TRANSPARENT_HUGE_PAGECACHE=y), I can consistently demonstrate ~300ms delay for a 1.4GiB output.
* Linux ext4: I don't measure any benefit, either backed by a hard disk or by a file in tmpfs.
* The current code organization of `defined(HAVE_POSIX_FALLOCATE)` costs us a macro dispatch for AIX.

I think we should just remove it. I think if posix_fallocate ever finds demonstrable benefit,
it is likely Linux specific and will not need HAVE_POSIX_FALLOCATE, and possibly opt-in by some specific programs.

In a filesystem with CoW and compression, the ENOSPC benefit may be lost as well.

Reviewed By: khng300

Differential Revision: https://reviews.llvm.org/D115957

More information about the All-commits mailing list