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 |
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel