Re: use of posix_fadvise/posix_fallocate

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> A complaint was recently raised on the cygwin list that the current cp
> algorithm for regular files leads to disk fragmentation, since files are
> only copied a block at a time.  In response, the cygwin developers
> implemented both posix_fadvise and posix_fallocate.  Would it be worth
> trying to write a gnulib module that provides substitutions for these
> functions on lacking platforms (posix_fadvise being a no-op, and
> posix_fallocate resolving to a call to ftruncate), then trying to improve
> the copy algorithm in copy_reg() to inform the kernel that the source file
> is read-once (POSIX_FADV_SEQUENTIAL, POSIX_FADV_NOREUSE), and that the

Well, POSIX_FADV_NOREUSE is not always appropriate.
However, sometimes it is.  For example, in a cross-device "mv" command,
we know we're going to remove the source right after copying it, so
POSIX_FADV_NOREUSE is exactly what we want.  So, making it an option,
at least internally might make sense.  Of course, I'd like to know
whether it makes an actual difference on a modern system or two.

> destination file is expected to occupy the same length as the source, so
> that the resulting copy is potentially faster and less likely to be
> fragmented on disk?

Disk fragmentation is an OS problem, not an application one,
and so unless you can show there's some benefit (and no downside)
for modern systems, I'd prefer to keep such changes cygwin-specific.
We've considered using posix_fadvise in cp before: here are
the starts of two related threads:

  http://lists.gnu.org/archive/html/bug-coreutils/2005-08/msg00090.html
  http://lists.gnu.org/archive/html/bug-coreutils/2005-08/msg00125.html

Can you quantify the problem on Cygwin?
However, if the problem is significant enough, I'd probably
accept a noninvasive patch.