On Tue, Jul 8, 2014 at 9:37 AM, Ivan Enderlin @ Hoa
<ivan.ender...@hoa-project.net> wrote:
> On 13/06/2014 16:20, Julien Pauli wrote:
>>
>> Hi,
>
> Hello :-),
>
>
>
>> I just wrote a patch to add fallocate() syscall support for streams.
>> It relies on posix_fallocate(), so that it should support many Unixes.
>> Linux's got a specification with a fallocate() function, more powerful
>> than the posix call.
>>
>> fallocate() does write blocks to the underlying filesystem (not so
>> many are supported, but the ones not supported should proxy to
>> ftruncate()) and prevents sparse file creation whereas ftruncate()
>> just updates inode information, leading to possible future out of
>> space errors.
>>
>> I got a POC showing the diffs between both calls here :
>> https://gist.github.com/jpauli/8afec7c4fc2b38f8ff27
>>
>> I propose two APIs for PHP :
>> - One that adds a function : fallocate()
>> https://github.com/jpauli/php-src/tree/fallocate
>
> I prefer this one.
>
>
>
>> - One that relies on ftruncate() , and adds a <bool>$use_fallocate
>> flag https://github.com/jpauli/php-src/tree/fallocate_flag
>>
>> Please, note that the latest proposal requires patches in different
>> extensions, as I changed a PHP_API function signature.
>>
>> I don't know if Windows can support that. Pierre, Anatol ? :-)
>>
>> Tests are beeing written at the moment.
>>
>> I didn't implement this is user stream handlers, as this really is a
>> low level implementation design that is kind of useless for usage in
>> user streams.
>>
>> Thoughts ?
>
> If the first one is used, please, consider exposing it on the user-land of
> stream wrappers (exemple: `stream_allocate`) if possible.

I find it very useless as user stream already have the ftruncate
exposed to them.
The difference between ftruncate and fallocate is meaningless in userland.

Julien.P

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to