|
Been running through my eternal testing regime ... and experimenting
with removing/adding bricks - to me, a necessary part of volume
maintenance for dealing with failed disks. The datastore is a VM
host and all the following is done live. Sharding is active with a
512MB shard size. So I started off with a replica 3 volume // recreated from memory I remove a brick with: gluster volume remove-brick datastore1 replica 2 vng.proxmox.softlog:/vmdata/datastore1 force so we end up with: Volume Name: datastore1 All well and good. No heal issues, VM's running ok. Then I clean the brick off the vng host: rm -rf /vmdata/datastore1 I then add the brick back with: gluster volume add-brick datastore1 replica 3 vng.proxmox.softlog:/vmdata/datastore1 This recreates the brick directory "datastore1". Unfortunately this is where things start to go wrong :( Heal info: gluster volume heal datastore1 info Its my understanding that there shouldn't be any heal entries on vng as it that is where all the shards should be sent *to* also running qemu-img check on the hosted VM images results in a I/O error. Eventually the VM's themselves crash - I suspect this is due to individual shards being unreadable. Another odd behaviour I get is if I run a full heal on vnb I get the following error: Launching heal operation to perform full self heal on volume datastore1 has been unsuccessful However if I run it on VNA, it succeeds. Lastly - if I remove the brick everythign returns to normal immediately. Heal Info shows no issues and qemu-img check returns no errors. -- Lindsay Mathieson |
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
