Chris, you should really load write-behind (and read-ahead) on the client side to gain on performance. Also on server side, server->write-behind->io-theads->posix helps. avati 2007/11/16, Chris Johnson <johnson@xxxxxxxxxxxxxxxxxxx>: > > On Fri, 16 Nov 2007, Anand Avati wrote: > > Doesn't get any simpler than this. > > volume client > type protocol/client > option transport-type tcp/client > option remote-host xxx.xxx.xxx.xxx > option remote-subvolume brick1 > end-volume > > Tx's are there to protect the inocent. > > > Your configuration doesnt seem to be what you want. do it someting like > this > > - > > > > volume brick1 > > .. > > end-volume > > > > volume write-behind > > ... > > subvolume brick1 > > end-volume > > > > volume read-ahead > > ... > > subvolume write-behind > > end-volume > > > > volume server > > ... > > auth.ip.read-ahead.allow * > > subvolume read-ahead > > end-volume > > > > > > also can you post your client config? > > > > avati > > > > 2007/11/16, Chris Johnson <johnson@xxxxxxxxxxxxxxxxxxx>: > >> > >> Ok, hi. > >> > >> I think I'm committing a major blunder here which may be why I'm > >> not seeing better through put. > >> > >> These xlators should be stacked, is that right? I defined the > >> following; > >> > >> volume brick1 > >> type storage/posix > >> option directory /home/sdm1 > >> end-volume > >> > >> volume server > >> type protocol/server > >> subvolumes brick1 > >> option transport-type tcp/server # For TCP/IP transport > >> # option client-volume-filename /etc/glusterfs/glusterfs-client.vol > >> option auth.ip.brick1.allow * > >> end-volume > >> > >> volume writebehind > >> type performance/write-behind > >> option aggregate-size 131072 # in bytes > >> subvolumes brick1 > >> end-volume > >> > >> volume readahead > >> type performance/read-ahead > >> option page-size 65536 ### in bytes > >> option page-count 16 ### memory cache size is page-count x page-size > >> per file > >> subvolumes brick1 > >> end-volume > >> > >> Should I have used the 'server' volume as the subvolume for read-ahead > >> and write-behind in the above? Or should read-ahead and write-behind > >> be between the basic brick and the server volume? Is there a > >> diffrence in performance? > >> > >> I grabbed 5 volumes from the SATA Beast. I think the best way to > >> test this is with the real files and jobs. So it's go for broke and > >> full bore time. > >> > >> If I have two front ends I need I'll need the postix lock deal, > >> the io threader is a must or why bother. If I unify, both front ends > >> need access to the same namespace brick so it has to have locks on it > >> too, yes? > >> > >> Looking at the GlusterFS Translators v1.3 server examples. Why > >> is the io thread xlator so high up in the stack? Would it be better > >> farther down that stack closer to the basic bricks? If not, why not? > >> > >> > >> > ------------------------------------------------------------------------------- > >> Chris Johnson |Internet: johnson@xxxxxxxxxxxxxxxxxxx > >> Systems Administrator |Web: > >> http://www.nmr.mgh.harvard.edu/~johnson > >> NMR Center |Voice: 617.726.0949 > >> Mass. General Hospital |FAX: 617.726.7422 > >> 149 (2301) 13th Street |Knowing what thou knowest not > >> Charlestown, MA., 02129 USA |is in a sence omniscience. Piet Hein > >> > >> > ------------------------------------------------------------------------------- > >> > >> > >> _______________________________________________ > >> 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 > > > > > ------------------------------------------------------------------------------- > Chris Johnson |Internet: johnson@xxxxxxxxxxxxxxxxxxx > Systems Administrator |Web: > http://www.nmr.mgh.harvard.edu/~johnson > NMR Center |Voice: 617.726.0949 > Mass. General Hospital |FAX: 617.726.7422 > 149 (2301) 13th Street |For all sad words of tongue or pen, the > saddest > Charlestown, MA., 02129 USA |are these: "It might have been". John G. > Whittier > > ------------------------------------------------------------------------------- > -- It always takes longer than you expect, even when you take into account Hofstadter's Law. -- Hofstadter's Law
