Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Matej Cepl on 2/27/2009 10:56 AM:
>>> +  /* posix_fallocate() is available since glibc 2.1.94.
>>> +   * fallocate is in Linux since kernel 2.6.23.
>>> +   */
>>> +  if (fallocate_mode)
>>> +    {
>>> +      int ret = 0;
>>> +      if ((ret = posix_fallocate (fd, 0, nsize)) != 0)
>> what if this function is not available?
> 
> That's the reason I mentioned in the comment since when 
> posix_fallocate is available, and the reason why I use 
> posix_fallocate(3) and not plain fallocate(2).  Isn't there some 
> minimal version of glibc required for coreutils?

No; in fact, coreutils must run on platforms that don't even use glibc;
and conversely, posix_fallocate is available on some of these systems
(think Solaris, cygwin 1.7, ...).  What you need to do is tackle the
problem by first writing a gnulib module for posix_fallocate.  Then we
need to make a choice.

Option 1: the gnulib replacement could guarantee contiguous allocation if
successful; and the replacement would fail with ENOSYS.  Coreutils then
gracefully deals with the failure, by informing the user that --allocate
can't work.

Option 2: generally, gnulib tries to go with merely good enough.  We can't
guarantee contiguous disk allocation, but we can at least guarantee
sufficient size.  The replacement can call ftruncate() or even lseek/write
under the hood, although you will need to ensure the resulting file is not
sparse.  And the coreutils documentation would then need to mention that
'truncate --allocate' attempts, but does not promise, contiguous
allocation, meaning that the speedup due to pre-allocation is only
noticeable on newer OS that support the full posix_fallocate semantics,
although the size guarantees are available on every OS.

Personally, I prefer option 2.

Meanwhile, you probably need to clear up your copyright assignment for
both coreutils and gnulib.

)I would suggest that on platforms where the function is lacking, that the
gnulib module emulate the fi

> 
> Otherwise, would something like
> 
>     #ifdef posix_allocate
> 
> work?

If you write a gnulib posix_fallocate module first, then you don't need
any #ifdefs on the coreutils side of things.  That's one of the reasons we
rely so heavily on gnulib.

>> so fallocate() rounds up to next multiple of block size?
> 
>>From fallocate manpage:
> 
> # Because allocation is done in block size chunks, fallocate() 
> # may allocate a larger range than that which was specified.
> 
>> That could be determined exactly.
>> Should we warn if user specifies a size that's not a multiple?

As long as we can truncate the file back to the requested size, the fact
that the contiguous disk allocation was rounded up to a larger size
shouldn't matter to the user.  So I don't think we need to warn.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmpO0AACgkQ84KuGfSFAYA9sQCg0KsEIoZjZIyL3unObX+fQM8G
mWMAoIfoZsUpFRNQHzZGPdrmrksTE8pv
=e2Zg
-----END PGP SIGNATURE-----