[Gluster-devel] libgfapi and any application

[Anand Avati]

Right, this is how the old booster worked. Booster was an LD_PRELOAD'able
module which used libglusterfsclient (previous incarnation of libgfapi) to
provide the exact functionality Joe is talking about. The
libglusterfsclient had both a gfapi-like filesystem API and a thin VFS-like
API on top. We would need such a thin VFS-like API on top of gfapi to make
such an LD_PRELOAD'able library possible.

I see RJ's reference to Parrot. Such a ptrace-like API has crossed my mind
in the past, and that would probably provide a more POSIX compliant
implementation than even LD_PRELOAD, but arguably not as high performant -
you still have context switches and memory copies like FUSE.

I would like to understand the motivation here, is it to benefit the gfapi
performance without incurring the app re-write?


On Mon, Apr 28, 2014 at 5:42 PM, Louis Zuckerman <me at louiszuckerman.com>wrote:

> I think that's how the old gluster booster lib worked.
>
>
> On Mon, Apr 28, 2014 at 8:21 PM, Joe Julian <joe at julianfamily.org> wrote:
>
>> Specifically I've been looking at the innodb engine for MariaDB. While
>> talking with Monty this weekend, he posited that I could write a wrapper
>> library to go around the innodb library that would handle the connection,
>> but would just override the glibc functions for posix filesystem commands.
>> Does this sound feasible?
>>
>> If it is, couldn't you essentially do an LD_PRELOAD wrapper around any
>> application to do that? Sure, you would have to probably resort to
>> environment variables to set the server and volume data, but in theory
>> would it work?
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140430/196b4dfd/attachment-0003.html>