1

I am triying to attach a brick from another server to a local gluster development server. Therfore I have done a dd from a snapshot on production and a dd on the lvm volume on development. Then I deleted the .glusterfs folder on root.

Unfortunatelly forming a new brick failed nevertheless with the info that this brick is already part of a volume. (how does gluster know that?!)

I then issued the following:

sudo setfattr -x trusted.gfid /bricks/staging/brick1/
sudo setfattr -x trusted.glusterfs.volume-id /bricks/staging/brick1/
sudo /etc/init.d/glusterfs-server restart

Magically gluster still seems to know that this brick is from another server as it knows the peered gluster nodes which are aparently different on the dev server:

sudo gluster volume create staging node1:/bricks/staging/brick1

Error msg:

volume create: staging: failed: Staging failed on gs3. Error: Host node1 is not in 'Peer in Cluster' state

Staging failed on gs2. Error: Host node1 is not in 'Peer in Cluster' state

Is there a way to achive a restorage of that brick on a new server? Thank you for any help on this.

0

You could check if the trusted.glusterfs.volume-id extended atribute is set to any of the directories in /bricks/staging/brick1/. This is whan Gluster uses to see if the brick is not part of an other volume (or placed inside an other brick).

$ sudo getfattr -e hex -n rusted.glusterfs.volume-id /bricks/staging/brick1
$ sudo getfattr -e hex -n rusted.glusterfs.volume-id /bricks/staging
$ sudo getfattr -e hex -n rusted.glusterfs.volume-id /bricks

If any of these show a volume-id, you can remove it with the setfattr command you used earlier.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.