On 01/09/2013 03:51 PM, Pranith Kumar K wrote:
On 01/07/2013 04:46 PM, Raghavendra Gowdappa wrote:
Pranith,
This comment is on the second patch. While the implementation looks
fine, I've some concerns related to the idea itself. Consider
following situation with a replicate volume of two subv
hi,
Appreciate everyone for the code-reviews. I will make the
changes suggested to the code. Before that, Do you have any comments on
re-open attempts? Are you guys ok with waiting for 1024 successes every
time? is 1024 ok? or should it be more. I am not sure how to arrive at a
good nu
On 01/07/2013 04:46 PM, Raghavendra Gowdappa wrote:
Pranith,
This comment is on the second patch. While the implementation looks fine, I've
some concerns related to the idea itself. Consider following situation with a
replicate volume of two subvolumes:
1. process 1 (p1) acquires a mandatory
"
> Cc: "Anand Avati" , "Amar Tumballi" ,
> "devel" ,
> "Mohammed Junaid"
> Sent: Monday, January 7, 2013 4:46:59 PM
> Subject: Re: [Gluster-devel] Need review for client-reopen changes
>
> Pranith,
>
> This comment is on the secon
Pranith,
This comment is on the second patch. While the implementation looks fine, I've
some concerns related to the idea itself. Consider following situation with a
replicate volume of two subvolumes:
1. process 1 (p1) acquires a mandatory lock.
2. stop first server, replace disk
3. reopen of
hi,
http://review.gluster.org/#change,4357
http://review.gluster.org/#change,4358
are the changes I made to handle re-opens of files in the case where a disk is
replaced while a brick is offline. The idea is to attempt re-opens after
self-heal completes and the file could be opened. With the
