Description of problem:
Some customers are making mistakes when attempting to re-initialize bricks for reuse. This can result in data loss. Currently there is no process to re-initialize a brick programmatically.
It would be good to have a function, either an option to the gluster command or a stand-alone tool, that will correctly re-initialize a previously used brick so that it can be reused, while providing informative feedback to the user and requiring explicit confirmation prior to making unrecoverable changes.
Additionally, it might be helpful to have the tool perform a rudimentary analysis of the brick (filesystem format, size, etc.) and report this to the user along with warnings if any of the suggested brick attributes are incorrect.
You can always reuse the brick using "force" command when creating volume.
What is your expectation with this RFE ? Do you wish to collect information of the old brick(like filesystem, size, used and free space, file count etc) and present to admin before using "force" option if he is trying to use old brick?
Or do you want user not to accidentally use a brick which is already used by other volume?
The original case is now closed but I think some combination of both. The intent being to prevent a user from inadvertently trashing a brick by mistake.
(In reply to Cal Calhoun from comment #5)
> The original case is now closed but I think some combination of both. The
> intent being to prevent a user from inadvertently trashing a brick by
As of now we do have check and we are preventing a user to inadvertently trashing a brick by mistake.
What I think improvement here we can make is...
As of now when we try to use a brick which is part of volume, it complains saying "brick already in use, use force to override ...something of this sort.
In addition to this we can even inform, brick is part of which volumes.
In case volume doesn't exist anymore, message can even indicate the volume doesn't exist any more.
Let me know how these changes sounds and do let us know if you have any more suggestion.
@Bipin, I think this would be a very good way to address the issue.
Can be considered for an enhancement in GD2..
@PPai, Aravinda - request you to evaluate this for GD2.