>
> Daniel,
> the ldpreload client traps open(), calls real_open(), and does
> fgetxattr(open_fd) to get the 'specification' on how to reach the booster
> xlator.. so each mountpoint will return its own specification to reach its
> own xlator.
Even though getting the 'specification' from a config file would be "faster"
(no queries at runtime), the current approach was chosen because we felt
0-configuration is far more appealing and also more intuitive in cases of
multiple mountpoints. Also the overhead is only during open() times
avati
avati
>
> 2007/11/2, Daniel van Ham Colchete <daniel.colchete@xxxxxxxxx>:
> >
> > Vikas,
> >
> > maybe I'm asking a very stupid question, but... May I assume that the
> > booster shared library will proxy the read and write requests to the
> > kernel
> > when it is not supposed to go to a glusterfs dir?
> >
> > Like, for example, if I have
> > /dev/sda4 = /home
> > glusterfs1 = /mnt/gluster1 // One server-farm
> > glusterfs2 = /mnt/gluster2 // Another independent server-farm
> >
> > open("/home/test1", O_RDWR) = 3;
> > open("/mnt/gluster1/test2", O_RDWR) = 4;
> > open("/mnt/gluster2/test3", O_RDWR) = 5;
> > write(3, "Daniel1"); // This goes to the kernel
> > write(4, "Daniel2"); // This goes directly to Gluster1
> > write(5, "Daniel3"); // This goes directly to Gluster2
> > close(3);
> > close(4);
> > close(5);
> >
> > Is it right? Will write(3, ...) go to the kernel, write(4, ...) to
> > Gluster1
> > and write(5, ...) to Gluster2?
> >
> > I'm sorry if it is too dumb (it really is)...
> >
> > The example with two different glusterfs is useless for me, I'm just
> > trying
> > to understand how it works. But, if this is true, I'll just add the the
> > booster library to my /etc/ld.so.preload before initiating any of the
> > services running on my servers.
> >
> > And, great job! This was a very very good idea!
> >
> > Best regards,
> > Daniel Colchete
> >
> > On Nov 1, 2007 4:51 PM, Vikas Gorur < vikas@xxxxxxxxxxxxx> wrote:
> >
> > > On 01/11/2007, Harris Landgarten <harrisl@xxxxxxxxxxxxx> wrote:
> > >
> > > > BTW,
> > > >
> > > > Is there any doc on booster?
> > >
> > > Here is some info about booster:
> > >
> > > --------
> > > The booster translator gives applications a faster path to communicate
> > > read and write requests to GlusterFS. Normally, all requests to
> > GlusterFS
> > > from
> > > applications go through FUSE. Using the booster translator in
> > conjunction
> > > with
> > > the GlusterFS booster shared library, an application can bypass the
> > FUSE
> > > path
> > > and send read/write requests directly to the GlusterFS client process.
> >
> > >
> > > The booster mechanism consists of two parts: the booster translator,
> > > and the booster shared library. The booster translator is meant to be
> > > loaded on the client side, usually at the root of the translator tree.
> >
> > > The booster shared library should be LD_PRELOAD'ed with the
> > > application.
> > >
> > > The booster translator when loaded opens a Unix domain socket and
> > > listens for read/write requests on it. The booster shared library
> > > intercepts read and write system calls and sends the requests to the
> > > GlusterFS process directly using the Unix domain socket, bypassing
> > FUSE.
> > > This leads to superior performance.
> > >
> > > Once you've loaded the booster translator in your volume specification
> >
> > > file, you
> > > can start your application as:
> > >
> > > $ LD_PRELOAD=/usr/local/bin/glusterfs-booster.so your_app
> > >
> > > The booster translator accepts no options (yet).
> > > -------
> > >
> > > Vikas
> > > --
> > > http://vikas.80x25.org/
> > >
> > >
> > > _______________________________________________
> > > Gluster-devel mailing list
> > > Gluster-devel@xxxxxxxxxx
> > > http://lists.nongnu.org/mailman/listinfo/gluster-devel
> > >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel@xxxxxxxxxx
> > http://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
>
>
>
> --
> It always takes longer than you expect, even when you take into account
> Hofstadter's Law.
>
> -- Hofstadter's Law
--
It always takes longer than you expect, even when you take into account
Hofstadter's Law.
-- Hofstadter's Law
