One more question. The documentation says: > NOTE: io-threads translator is useful when used over unify or just below server protocol in server side What about AFR translator ? Is it ok at all to have the following setup at the client side or io-translator must be after afr and before booster ? Or may be even better at server side ? volume brick1 type protocol/client option transport-type tcp/client # for TCP/IP transport option remote-host 10.0.0.1 # IP address of the remote brick option remote-subvolume vdsbrick # name of the remote volume end-volume ### Add client feature and attach to remote subvolume of server2 volume brick2 type protocol/client option transport-type tcp/client # for TCP/IP transport option remote-host 10.0.0.2 # IP address of the remote brick option remote-subvolume vdsbrick # name of the remote volume end-volume volume vdsafr type cluster/afr subvolumes brick1 brick2 end-volume volume vdsbooster type performance/booster #option transport-type tcp # Default is 'unix', which is mostly used when booster is loaded on client side. subvolumes vdsafr end-volume volume vdsiot type performance/io-threads subvolumes vdsbooster option thread-count 8 end-volume volume vdswb type performance/write-behind option aggregate-size 128KB # default is 0bytes option flush-behind on # default is 'off' subvolumes vdsiot end-volume volume vdsra type performance/read-ahead subvolumes vdswb end-volume Server side: volume vdsbrick type storage/posix option directory /var/lib/gluster/vds/ end-volume -- Best regards Anton Khalikov