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@xxxxxxxxxx > 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.
