[Gluster-devel] Memory leak
Anand Avati
avati at zresearch.com
Fri Mar 9 23:06:07 UTC 2007
That being said, the 'suggested' way of usage is:
performance/read-ahead : client side
performance/write-back : client side
performance/stat-prefetch: client side
performance/io-threads: server side
cluster/unify: client side
cluster/afr: client side
storage/posix: server side
protocol/client: client side
protocol/server: server side
before the 'optmizations' made the translators not loadable at certain
places, it was even possible to load protocol/client on server side in
the place of storage/posix and hence 'chain' glusterfsds! this infact
had helped a big deal in cornering memorly leaks and other troubles.
avati
On Fri, Mar 09, 2007 at 02:59:01PM -0800, Anand Avati wrote:
>
> >
> > Well, I didn't know I could even do a performance translator on the
> > server (glusterfsd)! All my performance translator tests are with the
> > client spec only. My server specs only contain storage/posix and
> > protocol/server. Client and server both are running on the same node(s).
> >
> > Are performance translators recommended/required for both client and
> > server processes? Can you do the cluster translators on the server-side,
> > too?
>
> The translator interface is such that theoretically you can load a
> translator anywhere. the only restriction they have is the number of
> child nodes (unify: 1 or more, performance/*: exactly 1,
> client/protocol: 0) Till recently, glusterfs was single threaded
> across and after we brought io-threads (initially aimed at server-side
> usage) the 'liberty' of loading any translator anywhere is slightly
> incorrect, but that is only temporary (till the non-threadsafe parts
> of the code are made threadsafe). Apart from thread-safety, there are
> few small (very minor) glitches (which got intrduced during the phase
> where we were optimizaing the system to decreae memory copies) which
> made stat-prefetch not loadable on server side. These problems will be
> fixed after the 1.3 release is made stable. the decision is to make
> the 'expected' usage style of translators work solidly, and then make
> 'any wierd configuration' work.
>
> So yes, say by 1.4 release, you will be able to load any translator
> anywhere. you can even have cluster/* trnalstors on server side (say
> you want to unify two mountpoints of two seperate hardisks or raid
> and export the aggregated mountpoint from glusterfsd)
>
> In the long run, though there are 'suggested' ways of using
> performance/ or features/ or cluster/ translators, any mix and match
> will be possible. That is when, we believe that your creativity will
> be the limit and glusterfs will be truly 'programmable' :)
>
> regards,
> avati
>
> --
> Shaw's Principle:
> Build a system that even a fool can use,
> and only a fool will want to use it.
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
--
Shaw's Principle:
Build a system that even a fool can use,
and only a fool will want to use it.
More information about the Gluster-devel
mailing list