I actually have 4 bricks with no arbiters. Fixed quorum count of 1 assures
the files will be accessible even if all but 1 brick go down. Performance
is good enough, though it can always be better, of course.
On Fri, Jan 18, 2019, 5:37 AM Andreas Davour On Fri, 18 Jan 2019, Diego Remolina wrote:
The OP (me) has a two node setup. I am not sure how many nodes in Artem's
configuration (he is running 4.0.2).
It can make sense that the more bricks you have, the higher the performance
hit in certain conditions, given that supposedly one of the issues of
gluster with many small files is that
When we first started with glusterfs and version 3 last year, we also had a
ton of performance issues, especially with small files. I've made several
reports at the time, hopefully some of them helped.
However, at some point, possibly after updating to v4 (currently using
4.0.2), the performance
Dear all,
I was running gluster 3.10.12 on a pair of servers and recently upgraded to
4.1.6. There is a cron job that runs nightly in one machine, which rsyncs
the data on the servers over to another machine for backup purposes. The
rsync operation runs on one of the gluster servers, which mounts
