Hide Forgot
one more update regarding this bug, if we take a distribute-replicate volume, something with this kind of config, root@Unbuntu:~# /root/glusterfs/inst/sbin/gluster volume info dr1 Volume Name: dr1 Type: Distributed-Replicate Status: Started Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: 10.1.12.25:/mnt/sdb1/d1 Brick2: 10.1.12.25:/mnt/sdb1/r1 Brick3: 10.1.10.154:/mnt/sdb1/d1 Brick4: 10.1.10.154:/mnt/r1 root@Unbuntu:~# here brick4 is on a non-xattr supported back-end, Still data creation happens on all the bricks. and if all the bricks except the brick4 are brought down, so GETting data via curl does not happen, as expected and the bringing them back curl works again to GET data. But again, should we allow data to get replicated on a brick having no back-end support for xattrs?
Presently if you take a a distribute volume with back end being a mix of having xattr support and non-xattr support. the dht allows the all of data to be stored on the brick , the one having the xattr support. though no data loss happens, but somewhere if can set some notification of the kind that the other brick is on top of a back-end having no xattr support, will be better as it may help user replace the brick accordingly.
CHANGE: http://review.gluster.com/542 (In this case, send setxattr to all the bricks to test user xattr support and return error if setxattr fails on even one of the bricks.) merged in master by Vijay Bellur (vijay)