Re: [Gluster-users] extreme slow recover rate

[Wei Dong]

There's one thing obviously wrong in the previous email.  GlusterFS is 
able to use more than one CPU core because we are running 4x4 I/O 
threads on each node.  I got the 99% number from ganglia output which is 
not correct.


Sorry for that

- Wei

Wei Dong wrote:

Hi All,

I'm experiencing extremely slow auto-heal rate with glusterfs and I 
want to hear from you guys to see if it seems reasonable or 
something's wrong.


I did a reconfiguration of the glusterfs running on our lab cluster.  
Originally we have 25 nodes, each provide 1 1.5T SATA disk, the data 
are not replicated.  Now we have expanded the cluster to 66 nodes and 
I decided to use all the 4 disks of each node and have the data 
replicated 3 times on different machines.  What I did is to leave the 
original data untouched, and reconfigure glusterfs so that the 
original data volumes are paired up with new empty mirror volumes.  On 
the server side, I have each node exports one volume for each of the 4 
disks, with an IO-threads translator with 4 threads running on top of 
each disk and no other performance translators.  On the client side 
which is mounted on each of the 66 nodes, I group all the volumes into 
mirrors of 3 volumes each, and then aggregate the mirrors with one 
DHT, and put a write-behind translator with window-size 1MB on top of 
that.


The files are all images, roughly 200K each.

To trigger auto-heal, I split a list of all the files (previously 
saved before reconfiguration) among the 66 nodes and have 4 threads on 
each nodes running the stat command on the files.  The overall rate is 
about 50 files per second, which I think is very low.  And will the 
auto-heal is running, all operations like cd and ls on the glusterfs 
client becomes extremely slow, each takes like one minute to finish.


On 
http://www.gluster.org/docs/index.php/GlusterFS_2.0_I/O_Benchmark_Results, 
which uses 5 servers and one raid0 disk each node, with 5 threads 
running on 3 clients, about 61K 1M files can be created within 10min, 
at an average rate of 130 files/second.  The glusterfsd processes are 
each taking about 99% CPU time (

we have 8 cores / node, but it seems glusterfsd is able to use only 1).

There only advantage is that they use RAID0 disk and clients and 
servers are different machines.  Other than that, we have more 
servers/clients, more disks on each node, and I have configured 
IO-thread and write-behind (which I don't think helps auto heal), and 
our files are only about 1/5 their size.  Even if I count each file as 
3 for replication, I'm only achieving similar throughput as a much 
smaller cluster.  I don't know why it's like this and following are my 
hypothesis:


1.  The overall through of glusterfs doesn't scale up to so many nodes;
2.  The auto-heal operating is slower than creating the file from 
scratch;
3.  Glusterfs is CPU bound -- it seems to be the case, but I'm 
unwilling to accept that a filesystem is CPU bound;
4.  The network bandwith is saturated.  I think we have 1gigabit 
eithernet on the nodes, which are on two racks and connected by some 
Foundry switch with 4 gigabit aggregate inter-rack bandwidth;

5.  Replication is slow.

Finally, the good news is that all the servers and client processes 
have been running for about 2 hours under stress, which I didn't 
expect in the beginning.  Good job you glusterfs people!


We are desperate for a shared storage and I'm eager to hear any 
suggestion you have to make glusterfs perform better.


- Wei



___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

[Gluster-users] extreme slow recover rate

[Wei Dong]

Hi All,

I'm experiencing extremely slow auto-heal rate with glusterfs and I want 
to hear from you guys to see if it seems reasonable or something's wrong.


I did a reconfiguration of the glusterfs running on our lab cluster.  
Originally we have 25 nodes, each provide 1 1.5T SATA disk, the data are 
not replicated.  Now we have expanded the cluster to 66 nodes and I 
decided to use all the 4 disks of each node and have the data replicated 
3 times on different machines.  What I did is to leave the original data 
untouched, and reconfigure glusterfs so that the original data volumes 
are paired up with new empty mirror volumes.  On the server side, I have 
each node exports one volume for each of the 4 disks, with an IO-threads 
translator with 4 threads running on top of each disk and no other 
performance translators.  On the client side which is mounted on each of 
the 66 nodes, I group all the volumes into mirrors of 3 volumes each, 
and then aggregate the mirrors with one DHT, and put a write-behind 
translator with window-size 1MB on top of that.


The files are all images, roughly 200K each.

To trigger auto-heal, I split a list of all the files (previously saved 
before reconfiguration) among the 66 nodes and have 4 threads on each 
nodes running the stat command on the files.  The overall rate is about 
50 files per second, which I think is very low.  And will the auto-heal 
is running, all operations like cd and ls on the glusterfs client 
becomes extremely slow, each takes like one minute to finish.


On 
http://www.gluster.org/docs/index.php/GlusterFS_2.0_I/O_Benchmark_Results, 
which uses 5 servers and one raid0 disk each node, with 5 threads 
running on 3 clients, about 61K 1M files can be created within 10min, at 
an average rate of 130 files/second.  The glusterfsd processes are each 
taking about 99% CPU time (

we have 8 cores / node, but it seems glusterfsd is able to use only 1).

There only advantage is that they use RAID0 disk and clients and servers 
are different machines.  Other than that, we have more servers/clients, 
more disks on each node, and I have configured IO-thread and 
write-behind (which I don't think helps auto heal), and our files are 
only about 1/5 their size.  Even if I count each file as 3 for 
replication, I'm only achieving similar throughput as a much smaller 
cluster.  I don't know why it's like this and following are my hypothesis:


1.  The overall through of glusterfs doesn't scale up to so many nodes;
2.  The auto-heal operating is slower than creating the file from scratch;
3.  Glusterfs is CPU bound -- it seems to be the case, but I'm unwilling 
to accept that a filesystem is CPU bound;
4.  The network bandwith is saturated.  I think we have 1gigabit 
eithernet on the nodes, which are on two racks and connected by some 
Foundry switch with 4 gigabit aggregate inter-rack bandwidth;

5.  Replication is slow.

Finally, the good news is that all the servers and client processes have 
been running for about 2 hours under stress, which I didn't expect in 
the beginning.  Good job you glusterfs people!


We are desperate for a shared storage and I'm eager to hear any 
suggestion you have to make glusterfs perform better.


- Wei
___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

[Gluster-users] glusterfs for cloud storage

[Wei Dong]

Hi All,

We are using glusterfs on our lab cluster for a shared storage to save a 
large number of image files, about 30 million at the moment.  We use 
Hadoop for distributed computing, but we are reluctant to store small 
files on hadoop for it's low throughput on small files and also the 
non-standard filesystem interface (e.g. we won't be able to run convert 
on each image to produce a thumbnail if the files are stored in 
hadoop).  What we do now is to store a list of paths to all images in 
hadoop, and use Hadoop streaming to pipe the paths to some script, which 
will then read the images from glusterfs filesystem and do the 
processing.  This has been working for a while so long as glusterfs 
doesn't hang, but the problem is that we basically lose all data 
locality.  We have 66 nodes and the chance that a needed file is on 
local disk is only 1/66, and 55/66 of file I/O has to go through 
network, which make me very uncomfortable.  I'm wondering if there's a 
better way of making glusterfs and Hadoop work together to take the 
advantage of data locality.


I know that there's a nufa translator which gives high preference to 
local drive.  This is good enough if the assignment of files to nodes is 
fixed.  But if we want to assign files to nodes according to the 
location of the file, what interface should we use to get the physical 
location of the file?


I appreciate all your suggestions.

- Wei Dong
___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

[Gluster-users] Another MySQL InnoDB locking issue: glusterfs2.0.6

[Mekathotti, Sudhakar]

> Hello,
> 
> Recently setup a 4 node replicated glusterfs. Trying to run mysql on
> it and coming across the following error.
> 
> mysqld[28115]: InnoDB: Check that you do not already have another
> mysqld process
> mysqld[28115]: InnoDB: using the same InnoDB data or log files.
> mysqld[28115]: InnoDB: Unable to lock ./ibdata1, error: 11
> 
> Exported filesystem is mounted on all 4 nodes.
> I've checked to make sure that there's no other instance running. I
> googled and found several others having issues with InnoDB on
> glusterfs, but couldn't find any solution. I would appreciate if you
> could take a quick look at the config files and see if there's
> anything I'm doing wrong. Configured using examples from gluster.org.
> 
> Apologies for long config listing...pastebin is blocked at work!!
> 
> Glusterfs: v 2.0.2-1 on Ubuntu server 9.04 x86_32  kernel: 2.6.28-14
> Fuse: 2.7.4-1
> 
> /etc/glusterfs/glusterfsd.vol:
> 
> volume posix
>   type storage/posix   # POSIX FS translator
>   option directory /srv/export# Export this directory
> end-volume
> 
> volume locks
>   type features/locks
>   subvolumes posix
> end-volume
> 
> volume brick
>   type performance/io-threads
>   option thread-count 8
>   subvolumes locks
> end-volume
> 
> volume server
>   type protocol/server
>   option transport-type tcp
>   option auth.addr.brick.allow *
>   subvolumes brick
> end-volume
> 
> /etc/glusterfs/glusterfs.vol:
> 
> volume remote1
>   type protocol/client
>   option transport-type tcp
>   option remote-host 192.168.1.2
>   option remote-subvolume brick
> end-volume
> 
> volume remote2
>   type protocol/client
>   option transport-type tcp
>   option remote-host 192.168.1.3
>   option remote-subvolume brick
> end-volume
> 
> volume remote3
>   type protocol/client
>   option transport-type tcp
>   option remote-host 192.168.1.4
>   option remote-subvolume brick
> end-volume
> 
> volume remote4
>   type protocol/client
>   option transport-type tcp
>   option remote-host 192.168.1.5
>   option remote-subvolume brick
> end-volume
> 
> volume replicate
>   type cluster/replicate
>   subvolumes remote1 remote2 remote3 remote4
> end-volume
> 
> volume writebehind
>   type performance/write-behind
>   option window-size 1MB
>   subvolumes replicate
> end-volume
> 
> volume cache
>   type performance/io-cache
>   option cache-size 512MB
>   subvolumes writebehind
> end-volume
> 
> 
> Many thanks
> Suds.
CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are 
confidential. If you are not the named recipient please notify the sender and 
immediately delete it. You may not disseminate, distribute, or forward this 
e-mail message or disclose its contents to anybody else. Copyright and any 
other intellectual property rights in its contents are the sole property of 
Cantor Fitzgerald and its affiliates.
E-mail transmission cannot be guaranteed to be secure or error-free. The sender 
therefore does not accept liability for any errors or omissions in the contents 
of this message, which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.
Although we routinely screen for viruses, addressees should check this e-mail 
and any attachments for viruses. We make no representation or warranty as to 
the absence of viruses in this e-mail or any attachments. Please note that to 
ensure regulatory compliance and for the protection of our customers and 
business, we may monitor and read e-mails sent to and from our server(s).
Any prices or data contained herein are indicative and subject to change 
without notice; its accuracy is not guaranteed and should not be relied on.  
Reliance may not be placed on trade confirmations issued other than by the 
Operations Department.
This e-mail was issued by Cantor Fitzgerald.  Cantor Fitzgerald Europe ("CFE") 
is regulated by the Financial Services Authority ("FSA"). CFE is an unlimited 
liability company incorporated under the laws of England  (company number 
2505767) and VAT registration (number 577 406809). CFE's registered office is 
at 17 Crosswall, London EC3N 2LB. For any issues arising from this email please 
reply to the sender.
CFE appears on the FSA register under no 149380. The FSA register appears at 
http://www.fsa.gov.uk/register/. The FSA regulates the financial services 
industry in the United Kingdom and is located at 25 The North Colonnade, Canary 
Wharf, London, E14 5HS.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

[Gluster-users] 2.0.6 problem / question

[Stephan von Krawczynski]

Hello all,

during testing we got the impression that re-activation of a dead secondary
gluster server by (all) clients does not work if the server was not active
during mount time on the clients. Is this a) true ? b) intended ?
We consider this behaviour a bug as there may well be situations where you
boot a client while one of the replication servers has troubles and is
therefore offline.
-- 
Regards,
Stephan
___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] Interesting experiment

[Moore, Michael]

Part of the performance loss is that you cannot get the full 4 Gbit of 
bandwidth between 2 hosts.  Usually you are limited to the throughput of a 
single link between 2 hosts.  And if you are using a round-robin method of 
bonding, then you run into performance losses due to TCP packets coming in out 
of order.

- Mike

-Original Message-
From: gluster-users-boun...@gluster.org 
[mailto:gluster-users-boun...@gluster.org] On Behalf Of Mickey Mazarick
Sent: Wednesday, August 19, 2009 4:19 PM
To: Nathan Stratton
Cc: gluster-users@gluster.org
Subject: Re: [Gluster-users] Interesting experiment

Just a note we initially tried to set up our storage network with bonded 
4 port gig E connections per client and storage node and it was still 
~1/3 the speed of infiniband.  There also appears to be more overhead in 
unwrapping data from packets even with jumbo frames set.

We did see about a 50% increase in throughput with 2 bonded gig ports, 
but not double the speed that you would expect. Make sure you use a 
trunking mechanism and not an active/passive configuration.

-Mic


Nathan Stratton wrote:
> On Wed, 19 Aug 2009, Hiren Joshi wrote:
>
>> Is it worth bonding? This look like I'm maxing out the network
>> connection.
>
> Yes, but you should also check out Infiniband.
>
> http://www.robotics.net/2009/07/30/infiniband/
>
>
>> <>
> Nathan StrattonCTO, BlinkMind, Inc.
> nathan at robotics.net nathan at blinkmind.com
> http://www.robotics.nethttp://www.blinkmind.com
> ___
> Gluster-users mailing list
> Gluster-users@gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] Update on internal development

[Stephan von Krawczynski]

On Wed, 19 Aug 2009 18:27:29 -0700
Anand Babu Periasamy  wrote:

> John Leach wrote:
> > On Tue, 2009-08-18 at 18:22 +0200, Stephan von Krawczynski wrote:
> >> On Tue, 18 Aug 2009 15:01:46 +0200
> > 
> >> And, I forgot to mention: it took me around 1 hour of bonnie to crash a 
> >> server
> >> in a classical distribute setup...
> >> Please stop featurism and start reliability.
> > 
> > Hi Stephan,
> > 
> > I just reviewed the GlusterFS commit logs for the release-2.0 branch and
> > *every single commit since Jul 17th has been a bug fix*, with a
> > reference to the bugzilla entry.
> > 
> > Practically all the commits before then through to May (where I gave up
> > looking) are also bugfixes, just without bugzilla references - I
> > couldn't find one serious new feature mentioned.
> > 
> > I'm not saying your problems aren't real, but the Z research folk do
> > seem to have been taking reliability seriously for a long time now.
> > 
> > John.
> 
> We are happy to see our community advocating both sides. Negative feedbacks 
> are
> important for us to improve.
> 
> 2.0 has been frozen since 2.0.0 release. New features are scheduled for 2.1 
> release.
> 
> Recently we recruited experienced storage professionals and created a RAS team
> (reliability, availability, serviceability). Their goal is to solely improve
> reliability and make GlusterFS resilient. Here are some of the initiatives..
> 
> * Automated regression / stress / functionality tests
> * Unit test framework
> * Patch-by-patch code audit
> * Increased the size of hardware lab significantly
> * Gtrace framework (similar solaris dtrace)
> 
> We are particularly excited about Gtrace, because it will help us narrow down 
> faults
> fairly quickly. Users will be able to report bugs by posting gtrace dumps 
> which contain
> complete information about the bug than log files. It is easier than 
> launching gdb or
> strace :).
> 
> You will also see a volume-generator tool to automatically generate volume 
> specification
> files. This avoids learning time and human-errors while crafting your volume 
> design.
> 
> Because GlusterFS runs on many hardware and operating system distributions, 
> it is very
> hard for us to test and certify all combinations. What makes worse is.. 
> GlusterFS itself
> is programmable. One solution to this problem is to reduce the number of 
> variables. Then
> it will allow us to certify those models. Volume specification generator will 
> have
> well tested options only.
> 
> Gluster Storage Platform with embedded kernel, web based management and 
> monitoring will
> remove most of the variables today. We will then be able to provide certified 
> list of
> hardware and client operating systems. We are also adding NFS, CIFS and 
> WebDAV support.
> 
> -- 
> Anand Babu Periasamy
> GPG Key ID: 0x62E15A31
> Blog [http://unlocksmith.org]
> GlusterFS [http://www.gluster.org]
> GNU/Linux [http://www.gnu.org]

If you want to hear my opinion on that:
stay with a successful strategy : keep it simple.
If you want to learn from a bad strategy look at btrfs. Take my word, it will
take at least 2-3 years until being really reliably useable, and then people
will realise it has become the brontosaurus of a fs: big, slow, eating lots of
resources, and doing everything beside the things really needed.
And some day then someone will understand the simple fact that a (local) fs
only needs few things:
- unlimited max size
- journals
- versioning / undelete by versioning
- _online_ userspace filesystem check
To make sure I cc'ed the "someone" ;-)

-- 
Regards,
Stephan

___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] Fwd: self-healing problem

[Christian Schab]

Am 20.08.2009 um 11:27 schrieb Vikas Gorur:



- "Christian Schab"  wrote:


When I use this option, and the file isn't available in "brick", does
it automatically loads the file from a fileserver?


Yes.


And now the old file ist now on the Fileserver again ... :-(


Can you try to reproduce this with the GlusterFS client running  
under TRACE

log level (-LTRACE) and post the client log?


I will try to.




I think your issue might be the same as one we found just a while ago:
http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=223

Please also post your kernel version and FUSE version.


Kernel: 2.6.21.7-2.fc8xen
fuse init (API version 7.8)
fuse distribution version: 2.7.3



Vikas
--
Engineer - http://gluster.com/



___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] Fwd: self-healing problem

[Vikas Gorur]

- "Christian Schab"  wrote:

> When I use this option, and the file isn't available in "brick", does
> it automatically loads the file from a fileserver?

Yes.
 
> And now the old file ist now on the Fileserver again ... :-(

Can you try to reproduce this with the GlusterFS client running under TRACE
log level (-LTRACE) and post the client log?

I think your issue might be the same as one we found just a while ago:
http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=223

Please also post your kernel version and FUSE version.

Vikas
--
Engineer - http://gluster.com/

___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] Fwd: self-healing problem

[Christian Schab]

Am 20.08.2009 um 10:28 schrieb Vikas Gorur:



- "Christian Schab"  wrote:


It is just used as another copy of data.
I feel like using such a local brick optimizes the performance very
much.


In that case you should set the option read-subvolume to "brick",
so that reads go to the local brick.



When I use this option, and the file isn't available in "brick", does  
it automatically loads the file from a fileserver?




No, we change file in the mounted directory.
So the new files is immediately replicated to the second fileserver.


Ok. Can you explain in more detail where you're doing the modification
from, and when self-heal is triggered?


The glusterfs mounted directory is alwasys called "/srv".

On Fileserver 1:
I copy a file from a local disk ('/root' for exaple) to '/srv/xxx/ 
.gif'.

Doing it on console or per ftp its the same here.
Making a 'ls -lh /srv/xxx/' shows the new file.

On FIleserver 2:
Making a 'ls -lh /srv/xxx/' shows the new file.

On Webserver:
Making a  'ls -lh /srv/xxx/' the first time shows the new file.
Making again 'ls -lh /srv/xxx/' shows the old file :-(

The log on the Webserver says:
afr: self-healing file /www//yyy.gif from subvolume brick to 2  
other



And now the old file ist now on the Fileserver again ... :-(

I hope this helps ...

Christian







Vikas
--
Engineer - http://gluster.com/



___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] Fwd: self-healing problem

[Vikas Gorur]

- "Christian Schab"  wrote:
 
> It is just used as another copy of data.
> I feel like using such a local brick optimizes the performance very  
> much.

In that case you should set the option read-subvolume to "brick",
so that reads go to the local brick.
 
> No, we change file in the mounted directory.
> So the new files is immediately replicated to the second fileserver.

Ok. Can you explain in more detail where you're doing the modification
from, and when self-heal is triggered?

Vikas
-- 
Engineer - http://gluster.com/

___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

[Gluster-users] Fwd: self-healing problem

[Christian Schab]

Hello Vikas,

thanks for your reply.



On each Webserver is a local brick used as a type of cache.


Can you explain a bit more about how the local brick is used
and why it's needed?


It is just used as another copy of data.
I feel like using such a local brick optimizes the performance very  
much.





Now when we change a file on a Fileserver.


Are you changing the file directly on the backend on a fileserver?


No, we change file in the mounted directory.
So the new files is immediately replicated to the second fileserver.


Vikas
--
Engineer - http://gluster.com/





Thanks for your help!

Christian

___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

Re: [Gluster-users] self-healing problem

[Vikas Gorur]

- "Christian Schab"  wrote:

> On each Webserver is a local brick used as a type of cache.

Can you explain a bit more about how the local brick is used
and why it's needed?
 
> Now when we change a file on a Fileserver.

Are you changing the file directly on the backend on a fileserver?

Vikas
-- 
Engineer - http://gluster.com/

___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users

[Gluster-users] self-healing problem

[Christian Schab]

Hello everybody,

I have problems with die self-healing function of the afr translator.

Our environment:
We have 2 Fileservers and a couple of Webservers.
Webservers are added and removed dynamically (it's in a cloud :-) )
(So i can't add them to the server configuration...)

On each Webserver is a local brick used as a type of cache.

Now when we change a file on a Fileserver.
The new file is replicated to the second Fileserver,
but the Webservers then start to "self-heal" this file.
afr: self-healing file /www//yyy.gif from subvolume brick to 2  
other

And all changes are lost :-(

"brick" is the local brick on the Webservers and shouldn't be used to  
self-heal.


I thought "favorite-child" helps, but it doesn't seem so.

Can I change the behavior so, that changed files won't be self-healed?


Thanks a lot for your help!

Christian





We are using this version on all servers:
glusterfs 2.0.2 built on Jun 27 2009 01:45:43
Repository revision: 07019da2e16534d527215a91904298ede09bb798
Copyright (c) 2006-2009 Z RESEARCH Inc. 
GlusterFS comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GlusterFS under the terms of the GNU  
General Public License.



Here is our server configuration:
volume posix
type storage/posix
option directory /mnt/ebs1
end-volume

volume ebs
  type features/locks
  option mandatory-locks on
  subvolumes posix
end-volume


volume server
type protocol/server
option transport-type tcp/server
option auth.addr.ebs.allow *
subvolumes ebs
end-volume



The clienst configuration:
volume posix
 type storage/posix
 option directory /mnt/ebs1
end-volume

volume locks
  type features/locks
  subvolumes posix
end-volume

volume brick
 type performance/io-threads
 subvolumes locks
end-volume

volume fileserver1
 type protocol/client
 option transport-type tcp
 option remote-host fileserver1
 option remote-subvolume ebs
end-volume

volume fileserver2
 type protocol/client
 option transport-type tcp
 option remote-host fileserver2
 option remote-subvolume ebs
end-volume

volume afr
  type cluster/replicate
  option favorite-child brick
  subvolumes fileserver1 fileserver2 brick
end-volume

volume writebehind
  type performance/write-behind
  option cache-size 1MB
  subvolumes afr
end-volume

volume cache
  type performance/io-cache
  option cache-size 512MB
  subvolumes writebehind
end-volume





___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users