[Gluster-devel] Reverse brick order in tier volume- Why?

[Ravishankar N]

Hello,

When you perform a tier-attach, why are the bricks attached in the 
reverse order?

For example:
----------------------------
#gluster v create testvol  replica 3 
127.0.0.2:/home/ravi/bricks/brick{1..3} force
#gluster volume tier testvol attach replica 3 
127.0.0.2:/home/ravi/bricks/brick{4..9}
#gluster v info

Volume Name: testvol
Type: Tier
Volume ID: 2400b2d7-9f66-4e98-9357-f80baf282853
Status: Created
Number of Bricks: 9
Transport-type: tcp
Hot Tier :
Hot Tier Type : Distributed-Replicate
Number of Bricks: 2 x 3 = 6
Brick1: 127.0.0.2:/home/ravi/bricks/brick9
Brick2: 127.0.0.2:/home/ravi/bricks/brick8
Brick3: 127.0.0.2:/home/ravi/bricks/brick7
Brick4: 127.0.0.2:/home/ravi/bricks/brick6
Brick5: 127.0.0.2:/home/ravi/bricks/brick5
Brick6: 127.0.0.2:/home/ravi/bricks/brick4
Cold Tier:
Cold Tier Type : Replicate
Number of Bricks: 1 x 3 = 3
Brick7: 127.0.0.2:/home/ravi/bricks/brick1
Brick8: 127.0.0.2:/home/ravi/bricks/brick2
Brick9: 127.0.0.2:/home/ravi/bricks/brick3
Options Reconfigured:
cluster.tier-mode: cache
features.ctr-enabled: on
performance.readdir-ahead: on
----------------------------

Because it is this way, there is a lot of code written in cli and 
glusterd to handle this reverse order. It is rather counter-intuitive 
that when you do a `list_for_each_entry (brickinfo, &volinfo->bricks, 
brick_list)`, you get brick9..brick4 (in reverse order) and then 
brick1..brick3 in the forward order.

For arbiter volumes the 3rd brick of a 3 way replica is the arbiter (for 
eg, in {b1,b2, b3} , b3 is arbiter). In the above example, if we were to 
support an arbiter volume as hot-tier, b7 and b4 would be the arbiter 
bricks, instead of the intuitive b6 and b9. Of course we could always 
code it to whatever we want, but my real question boils down to

1) Is there is a compelling reason as to why the bricks of hot-tier are 
in the reverse order ?
2) If there isn't one, should we spend time to fix it so that the bricks 
appear in the order in which they were given at the time of volume 
creaction/ attach-tier *OR*  just continue with the way things are 
currently because it is not that much of an issue?

Thanks,
Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160119/e1e8179e/attachment.html>