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@xxxxxxxxxxxxxxxxxx> wrote:
I think that's how the old gluster booster lib worked.On Mon, Apr 28, 2014 at 8:21 PM, Joe Julian <joe@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
