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