http://www.gluster.org/community/documentation/index.php/Archives/Development_Work_Flow
http://www.gluster.org/community/documentation/index.php/Simplified_dev_workflow
Leaving the fun of exploration to you :)
~Joe
- Original Message -
> From: "Ajil Abraham"
Sure Atin. I am itching to contribute code. But worried due to lack of
experience in sending patches. Can somebody please send me across how to do
this? Consider me a total newbie and please be as descriptive as possible
:).
-Ajil
On Sat, Mar 5, 2016 at 12:46 PM, Atin Mukherjee
'brick_up_status' is used by the following .ts in release-3.7
[root@ravi1 glusterfs]# git grep -w brick_up_status
tests/bugs/bitrot/bug-1288490.t:EXPECT_WITHIN $PROCESS_UP_TIMEOUT "Y"
brick_up_status $V0 $H0 $B0/brick0
tests/bugs/bitrot/bug-1288490.t:EXPECT_WITHIN $PROCESS_UP_TIMEOUT "Y"
On 03/04/2016 08:36 PM, Shyam wrote:
On 03/04/2016 07:30 AM, Pranith Kumar Karampuri wrote:
On 03/04/2016 05:47 PM, Bipin Kunal wrote:
HI Pranith,
Thanks for starting this mail thread.
Looking from a user perspective most important is to get a "good copy"
of data. I agree that people
In order to estimate GlusterFS arbiter brick size, I've deployed test setup
with replica 3 arbiter 1 volume within one node. Each brick is located on
separate HDD (XFS with inode size == 512). Using GlusterFS v3.7.6 + memleak
patches. Volume options are kept default.
Here is the script that
On 03/04/2016 09:10 PM, Jeff Darcy wrote:
I like the default to be 'none'. Reason: If we have 'auto' as quorum for
2-way replication and first brick dies, there is no HA. If users are
fine with it, it is better to use plain distribute volume
"Availability" is a tricky word. Does it mean