[Gluster-devel] Memory leak

[Anand Avati]

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.