gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Booster documentation


From: Anand Avati
Subject: Re: [Gluster-devel] Booster documentation
Date: Fri, 2 Nov 2007 22:34:13 +0530

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.

avati

2007/11/2, Daniel van Ham Colchete <address@hidden>:
>
> 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 <address@hidden> wrote:
>
> > On 01/11/2007, Harris Landgarten <address@hidden> 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
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]