Re: AFR between two bricks over 3000 miles

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

 



On Sat, 1 Mar 2008, Krishna Srinivas wrote:

Nathan,

Check the performance by bringing writebehind into the picture your
config file shows that WB and iocache translators are not being used.

Sorry, that was stupid, changed it to subvolumes nyc sjc_write-behind that changed the delay to real 0m53.005s, still a far cry from .03 I get local. This is only 748K, so I would expect it to write local and write behind the 800K to the remote site.


On Sat, Mar 1, 2008 at 8:48 AM,  <nathan@xxxxxxxxxxxx> wrote:

 /etc/sysconfig is only 748K
 cp /etc/sysconfig to /share/mirror took real    0m55.319s
 cp /etc/sysconfig to /share took real    0m0.030s

 I expected it to be much faster. :)

 # Client
 volume nyc
   type protocol/client
   option transport-type tcp/client
   option remote-host 10.11.0.1
   option remote-subvolume nyc
 end-volume

 volume sjc
   type protocol/client
   option transport-type tcp/client
   option remote-host 10.12.0.1
   option remote-subvolume sjc
 end-volume

 volume sjc_iocache
   type performance/io-cache
   option page-size 256KB
   option page-count 2
   subvolumes sjc
 end-volume

 volume sjc_write-behind
   type performance/write-behind
   option aggregate-size 1MB
   option flush-behind on
   subvolumes sjc_iocache
 end-volume

 volume mirror
   type cluster/afr
   subvolumes nyc sjc
 end-volume



><>
 Nathan Stratton
 nathan at robotics.net
 http://www.robotics.net



 On Thu, 28 Feb 2008, Anand Avati wrote:

> on the client. you also might want to put this write-behind + io-cache pair
> in the subvolume path of afr which leads towards the remote site alone. Also
> make sure afr does not have the remote site as the first subvolume, and has
> the option read-subvolume <local-volume> so that reads are not scheduled to
> the remote site.
>
> avati
>
> 2008/2/28, nathan@xxxxxxxxxxxx <nathan@xxxxxxxxxxxx>:
>>
>>
>> On Thu, 28 Feb 2008, Anand Avati wrote:
>>
>>> using a combination of write-behind with io-threads (with option
>>> flush-behind on) prevents the wait of upto N-MB of data (where N is
>> 'option
>>> cache-size NMB' of io-threads)
>>
>>
>> Client and server are on each host, should I do this on the client or
>> server?
>>
>> -Nathan
>>
>
>
>
> --
> If I traveled to the end of the rainbow
> As Dame Fortune did intend,
> Murphy would be there to tell me
> The pot's at the other end.
>


 _______________________________________________
 Gluster-devel mailing list
 Gluster-devel@xxxxxxxxxx
 http://lists.nongnu.org/mailman/listinfo/gluster-devel






[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux