Downstream bug: https://bugs.debian.org/911118

Currently, truncate -s 100M 100M on a smbd mount where the backing filesystem doesn't have fallocate(2) will use the glibc fallback in posix_fallocate(3):
  [pid 3565208] pwrite64(28, "\0", 1, 103092223) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103096319) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103100415) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103104511) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103108607) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103112703) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103116799) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103120895) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103124991) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103129087) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103133183) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103137279) = 1
  [pid 3565208] pwrite64(28, "\0", 1, 103141375) = 1

Since samba has an explicit fallback that's more syscall-efficient (and should have the buffer size bumped from 32k), it should use fallocate(2) instead of posix_fallocate(3).

On musl they're the same (both as-if fallocate(2)), but on glibc, posix_fallocate(3) falls back to one-byte-at-a-time writes.