Re: Implemented fallocate() syscall in streams
| From: | Julien Pauli | Date: | Thu, 10 Jul 2014 09:13:10 +0000 |
| Subject: | Re: Implemented fallocate() syscall in streams | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-75352@lists.php.net to get a copy of this message | ||
On Tue, Jul 8, 2014 at 2:31 PM, Ivan Enderlin @ Hoa
<ivan.enderlin@hoa-project.net> wrote:
>
> On 08/07/2014 11:08, Julien Pauli wrote:
>>
>> On Tue, Jul 8, 2014 at 9:37 AM, Ivan Enderlin @ Hoa
>> <ivan.enderlin@hoa-project.net> wrote:
>>>
>>> On 13/06/2014 16:20, Julien Pauli wrote:
>>>>
>>>> - 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.
>
> Hum no, this is very useful actually. A stream wrapper can be used to
> represent a file somewhere else, imagine ntfs://,
> smb://, aws://,
> ftp://,
> afp://` etc.
>
>
>
>> The difference between ftruncate and fallocate is meaningless in userland.
>
> If fallocate is proposed in the user-land, then it will be
> logical to have
> it in the stream wrapper API. That's it :-).
I admit that it would be nice for consistency, however I wonder how
users will interpret the difference between ftruncate and fallocate.
Julien