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 How reproducible: 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. Actual results: Gluster runs "volume remove-brick $volume $brick force". Data is lost. Expected results: Either print the usage, or default to start instead of force. Additional info:
Hi, 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