See below for what I'm currently running. I'm testing without readahead at the moment - I haven't seen it fail with it commented out so far, but it's too early to tell.
Before I added the trace translator the error rate was much higher. After I added it, it took several hours before it started failing, even though I've excluded almost all the calls.
I can only reproduce it when I add the server in question to our production cluster, unfortunately - I've tried repeatedly to reproduce it with a test environment, but I'm clearly missing out on some element of the access pattern we see in production. I should probably try to replay the requests from our access logs or something.
volume webcluster1
type protocol/client
option transport-type tcp/client
option remote-host 192.168.165.13
option remote-subvolume webcluster
end-volume
volume webcluster2
type protocol/client
option transport-type tcp/client
option remote-host 192.168.165.11
option remote-subvolume webcluster
end-volume
### Replication
volume afr
type cluster/afr
subvolumes webcluster1 webcluster2
end-volume
### Performance
#volume readahead
# type performance/read-ahead
# option page-count 2 # cache per file = (page-count x page-size)
# subvolumes afr
#end-volume
### Add IO-Cache feature
volume iocache
type performance/io-cache
option page-size 256KB
subvolumes afr #readahead
end-volume
### Add writeback feature
volume writeback
type performance/write-behind
option flush-behind off
subvolumes iocache
end-volume
volume trace
type debug/trace
subvolumes writeback
# option include open,close,create,readdir,opendir,closedir
option exclude lookup,read,write,open,close,create,readdir,opendir,closedir,flush,readlink,fstat,stat
end-volume
On Wed, Jun 24, 2009 at 10:15 AM, Vikas Gorur
<address@hidden> wrote:
----- "Vidar Hokstad" <address@hidden> wrote:
What is your client configuration? Do you have a way to reproduce this?
Vikas
--
Engineer - http://gluster.com/
A: Because it messes up the way people read text.
Q: Why is a top-posting such a bad thing?
--