Great Avati, thanks!
Can't wait to the 1.3.8 release!
Best,
Daniel
On Nov 2, 2007 3:24 PM, Anand Avati <avati@xxxxxxxxxxxxx> wrote:
> 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
>
