[Top][All Lists]

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

Re: [Gluster-devel] Full bore.

From: Chris Johnson
Subject: Re: [Gluster-devel] Full bore.
Date: Fri, 16 Nov 2007 11:24:05 -0500 (EST)

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
  option remote-subvolume brick1

     Tx's are there to protect the inocent.

Your configuration doesnt seem to be what you want. do it someting like this

volume brick1

volume write-behind
 subvolume brick1

volume read-ahead
 subvolume write-behind

volume server
 ... *
 subvolume read-ahead

also can you post your client config?


2007/11/16, Chris Johnson <address@hidden>:

      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

volume brick1
   type storage/posix
   option directory /home/sdm1

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 *

volume writebehind
   type performance/write-behind
   option aggregate-size 131072 # in bytes
   subvolumes brick1

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

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: address@hidden
Systems Administrator       |Web:
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

It always takes longer than you expect, even when you take into account
Hofstadter's Law.

-- Hofstadter's Law

------------------------------------------------------------------------------- Chris Johnson |Internet: address@hidden
Systems Administrator       |Web:
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 -------------------------------------------------------------------------------

reply via email to

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