Red Hat Bugzilla – Bug 834729
gluster volume remove-brick defaults to force commit, and causes data loss
Last modified: 2014-03-18 08:16:17 EDT
Description of problem:
Running "gluster volume remove-brick $volume $brick" without any arguments runs force commit, which causes loss of data (though it warns you). You are not told that the default is force commit. Defaulting to start, or not defaulting at all may be more user friendly.
Version-Release number of selected component (if applicable):
glusterfs 3.3.0 built on May 31 2012 11:16:29
Steps to Reproduce:
1.Have a started redistribute gluster volume with at least 2 bricks and several files.
2.Remove gluster volume without specifying any options: "gluster volume remove-brick $volume $brick".
3.ls the gluster volume, there are less files than you began with.
Gluster runs "volume remove-brick $volume $brick force". Data is lost.
Either print the usage, or default to start instead of force.
Actually the behavior is because of backward compatibility with 3.1.x and 3.2.x versions. In those versions there was no 'start' option, and hence it used to remove bricks. We kept the same behavior with 3.3.0 too. That is the reason why you get the question when you just do remove-brick without options, asking if its ok to continue because there can be data loss.
This is not a bug, but the intended behavior considering the backward compatibility.
as explained in comment #1