Re: [Gluster-users] Impact of force option in remove-brick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ok thanks.

On Tue, Mar 22, 2016 at 12:45 PM, Atin Mukherjee <amukherj@xxxxxxxxxx> wrote:


On 03/22/2016 12:42 PM, ABHISHEK PALIWAL wrote:
>
>
> On Tue, Mar 22, 2016 at 12:38 PM, Atin Mukherjee <amukherj@xxxxxxxxxx
> <mailto:amukherj@xxxxxxxxxx>> wrote:
>
>
>
>     On 03/22/2016 12:23 PM, ABHISHEK PALIWAL wrote:
>     >
>     > On Tue, Mar 22, 2016 at 12:14 PM, Gaurav Garg <ggarg@xxxxxxxxxx <mailto:ggarg@xxxxxxxxxx>
>     > <mailto:ggarg@xxxxxxxxxx <mailto:ggarg@xxxxxxxxxx>>> wrote:
>     >
>     >     >> I just want to know what is the difference in the following
>     scenario:
>     >
>     >     1. remove-brick without the force option
>     >     2. remove-brick with the force option
>     >
>     >
>     >     remove-brick without force option will perform task based on your
>     >     option,
>     >     for eg. remove-brick start option will start migration of file
>     from
>     >     given
>     >     remove-brick to other available bricks in the cluster. you can
>     check
>     >     status
>     >     of this remove-brick task by issuing remove-brick status command.
>     >
>     >     But remove-brick with force option will just forcefully remove
>     brick
>     >     from the cluster.
>     >     It will result in data loss in case of distributed volume, because
>     >     it will not migrate file
>     >     from given remove-brick to other available bricks in the
>     cluster. In
>     >     case of replicate volume
>     >     you might not have problem by doing remove-brick force because
>     later
>     >     on after adding brick you
>     >     can issue heal command and migrate file from first replica set to
>     >     this newly added brick.\
>     >
>     >
>     > so when you are saying the forcefully remove the brick means it will
>     > remove the brick even when
>     > that brick is not available or available but have the different
>     uuid of
>     > peers, without generating any error?
>     As I mentioned earlier it doesn't make sense to differentiate between
>     these two behaviors until the UUID mismatch issue is resolved.
>
>
> Yes, I agree. but how we can resolve that uuid mismatch issue is there
> any way for the same in running system?
I've explained the case why you are running into multiple UUIDs here [1].

[1] http://www.gluster.org/pipermail/gluster-users/2016-March/025912.html
>
>     >
>     >
>     >     Thanks,
>     >
>     >     ~Gaurav
>     >
>     >     ----- Original Message -----
>     >     From: "ABHISHEK PALIWAL" <abhishpaliwal@xxxxxxxxx <mailto:abhishpaliwal@xxxxxxxxx>
>     >     <mailto:abhishpaliwal@xxxxxxxxx <mailto:abhishpaliwal@xxxxxxxxx>>>
>     >     To: gluster-users@xxxxxxxxxxx <mailto:gluster-users@xxxxxxxxxxx>
>     <mailto:gluster-users@xxxxxxxxxxx <mailto:gluster-users@xxxxxxxxxxx>>,
>     >     gluster-devel@xxxxxxxxxxx <mailto:gluster-devel@xxxxxxxxxxx>
>     <mailto:gluster-devel@xxxxxxxxxxx <mailto:gluster-devel@xxxxxxxxxxx>>
>     >     Sent: Tuesday, March 22, 2016 11:35:52 AM
>     >     Subject: [Gluster-users] Impact of force option in remove-brick
>     >
>     >     Hi Team,
>     >
>     >     I have the following scenario:
>     >
>     >     1. I have one replica 2 volume in which two brick are available.
>     >     2. in such permutation and combination I got the UUID of peers mismatch.
>     >     3. Because of UUID mismatch when I tried to remove brick on the
>     >     second board I am getting the Incorrect Brick failure.
>     >
>     >     Now, I have the question if I am using the remove-brick command with
>     >     the 'force' option it means it should remove the brick in any
>     >     situation either the brick is available or its UUID is mismatch.
>     >
>     >     I just want to know what is the difference in the following scenario:
>     >
>     >     1. remove-brick without the force option
>     >     2. remove-brick with the force option
>     >
>     >
>     >     Regards
>     >     Abhishek
>     >
>     >     _______________________________________________
>     >     Gluster-users mailing list
>     >     Gluster-users@xxxxxxxxxxx <mailto:Gluster-users@xxxxxxxxxxx>
>     <mailto:Gluster-users@xxxxxxxxxxx <mailto:Gluster-users@xxxxxxxxxxx>>
>     >     http://www.gluster.org/mailman/listinfo/gluster-users
>     >
>     >
>     >
>     >
>     > --
>     >
>     >
>     >
>     >
>     > Regards
>     > Abhishek Paliwal
>     >
>     >
>     > _______________________________________________
>     > Gluster-users mailing list
>     > Gluster-users@xxxxxxxxxxx <mailto:Gluster-users@xxxxxxxxxxx>
>     > http://www.gluster.org/mailman/listinfo/gluster-users
>     >
>
>
>
>
> --
>
>
>
>
> Regards
> Abhishek Paliwal



--




Regards
Abhishek Paliwal
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux