Pádraig Brady wrote:
> Bruno Haible wrote:
>>
>> The return value convention described in
>> http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html
>> is a different one. Either this code or that man page is wrong.
>
> I don't follow. Both return int. ENOSYS to me means it can't
Bruno Haible wrote:
> Pádraig Brady wrote:
>> Take 2 attached.
>
> Take 2 review:
>
>> +#ifdef REPLACE_FALLOCATE
>
> The generated fcntl.h should be maximally standalone. Can you better use
> #if @REPLACE_FALLOCATE@ and use an AC_SUBSTed variable REPLACE_FALLOCATE
> instead of one defined in con
Pádraig Brady wrote:
> Take 2 attached.
Take 2 review:
> +#ifdef REPLACE_FALLOCATE
The generated fcntl.h should be maximally standalone. Can you better use
#if @REPLACE_FALLOCATE@ and use an AC_SUBSTed variable REPLACE_FALLOCATE
instead of one defined in config.h?
> +# undef fallocate
Why the
Eric Blake wrote:
> According to Pádraig Brady on 5/27/2009 10:20 AM:
>> Take 2 attached.
>
>> Still outstanding from the gnulib portion is support for solaris.
>> I may get time to set this up, but I've very little time lately,
>> so I would like not to require this for merging.
>
> That seems l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 5/27/2009 10:20 AM:
> Take 2 attached.
>
> Still outstanding from the gnulib portion is support for solaris.
> I may get time to set this up, but I've very little time lately,
> so I would like not to require this for mer
Take 2 attached.
Still outstanding from the gnulib portion is support for solaris.
I may get time to set this up, but I've very little time lately,
so I would like not to require this for merging.
Also I didn't yet implement the optimization to coreutils
that Paul mentioned, to cache whether the
Paul Eggert wrote:
> Pádraig Brady writes:
>
>> Well libc, kernel or filesystem could return ENOSYS
>> so code using fallocate() has to handle it anyway.
>
> If memory serves, ordinarily gnulib tries to catch such situations,
> and to substitute a working function when the kernel just has a stub
Pádraig Brady writes:
> Well libc, kernel or filesystem could return ENOSYS
> so code using fallocate() has to handle it anyway.
If memory serves, ordinarily gnulib tries to catch such situations,
and to substitute a working function when the kernel just has a stub
that returns ENOSYS. However,
Bruno Haible wrote:
> Hello Pádraig,
>
> The documentation files you sent document the status before any 'fallocate'
> module is added to gnulib. So I committed them for you:
>
> 2009-05-21 Pádraig Brady
>
> * doc/glibc-functions/fallocate.texi: New file.
> * doc/gnulib.texi: Incl
Hello Pádraig,
The documentation files you sent document the status before any 'fallocate'
module is added to gnulib. So I committed them for you:
2009-05-21 Pádraig Brady
* doc/glibc-functions/fallocate.texi: New file.
* doc/gnulib.texi: Include it.
The fallocate.texi will n
Pádraig Brady wrote:
>
> I noticed another thread with more info about fallocate:
> https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html
>
> That got me thinking about whether we should use fallocate()
> if available in cp etc. so ext4 etc. can allocate optimally?
Here is a
11 matches
Mail list logo
