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

[Pádraig Brady]

Eric Blake wrote:
> 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.

Me too.
I think gnulib should just provide posix_fallocate which I would guess
is implemented in glibc as you describe in 2. I.E.

#ifdef FALLOCATE_AVAILABLE
 if (fallocate())
   return OK;
 else /* filesystem or operating system does not support */
#else
   for (each block)
      write(fd, 1); /* write 1 char to allocate block */
#endif

> 
> 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.

sounds like a good solution

cheers,
Pádraig.