IMHO, if a command will result in data loss, fall it. Period.
It should never be ok for a filesystem to lose data. If someone wanted to do that with ext or xfs they would have to format.
On November 14, 2016 8:15:16 AM PST, Ravishankar N <ravishankar@xxxxxxxxxx> wrote:
On 11/14/2016 05:57 PM, Atin Mukherjee
wrote:
This would be a straight forward thing to implement
at glusterd, anyone up for it? If not, we will take this into
consideration for GlusterD 2.0.
I don't think this is a good idea. It would make more sense
to give out verbose warnings in the individual commands
themselves. A volume lock doesn't prevent users from unlocking and
still inadvertently running those commands without knowing the
implications. The remove brick set of commands provides verbose
messages nicely:
$gluster v remove-brick testvol
127.0.0.2:/home/ravi/bricks/brick{4..6} commit
Removing brick(s) can result in data loss. Do you want to
Continue? (y/n) y
volume remove-brick commit: success
Check the removed bricks to ensure all files are
migrated.
If files with data are found on the brick path, copy them
via a gluster mount point before re-purposing the removed brick
My 2 cents,
Ravi
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
--
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
