Emmanuel Dreyfus wrote:
> [client-rpc-fops.c:1525:client3_3_inodelk_cbk] 0-patchy-client-1:
> remote operation failed: Resource temporarily unavailable
> [client-rpc-fops.c:1525:client3_3_inodelk_cbk] 0-patchy-client-0:
> remote operation failed: Resource temporarily unavailable
A focus on wha
Answers INLINE JOE>>
- Original Message -
From: "Venky Shankar"
To: "Joseph Fernandes"
Cc: "Kotresh Hiremath Ravishankar" , "Gluster Devel"
, dlamb...@redhat.com, "Vijay Bellur"
Sent: Friday, December 5, 2014 11:10:10 PM
Subject: Re: [Gluster-devel] Discussion: Implications on geo-rep
Emmanuel Dreyfus wrote:
> The file that cannot heal is gfid dae15ff0-0b16-4ca0-b27d-734f9d2290f8.
> You can see that the sweep completes, but the file is not reported as healed.
I note that in afr_selfheal_metadata(), if we fail to acquire a lock, we
try to unlock inodes we do not have lock for.
Krutika Dhananjay wrote:
> Could you provide the trace logs you had added with this failure?
A bit different since I had tossed out the previous trace logs.
The file that cannot heal is gfid dae15ff0-0b16-4ca0-b27d-734f9d2290f8.
You can see that the sweep completes, but the file is not report
On Fri, Nov 28, 2014 at 10:00 PM, Vijay Bellur wrote:
> On 11/28/2014 08:30 AM, Venky Shankar wrote:
>>
>> [snip]
>>>
>>>
>>> 1. Can the bitd be one per node like self-heal-daemon and other "global"
>>> services? I worry about creating 2 * N processes for N bricks in a node.
>>> Maybe we can consi
With the upcoming data compliance features in GlusterFS, a common
> infrastructure[1] to support various mechanisms such as tiering, bitrot
> detection etc. would prove to be helpful. Such an infrastructure extends
> the current changelog design (keeping NSR in mind) and removes
> constraints that
On Thu, Dec 4, 2014 at 10:42 PM, Joseph Fernandes wrote:
> On the performance on the data path I have seen a 3% dip in performance, with
> initial implementation which is not finalized.
> The testing is in progress and not finalized yet as we are trying to reduce
> it as much as possible, with o
Emmanuel Dreyfus wrote:
> OTOH, it seems to have fixed self-heald.t which suffered a similar problem
> on the test commented as "Test that ongoing IO is not considered as
> Pending heal"
>
> I have to test a bit more to be sure.
After more test it still fails on self-heald.t.
--
Emmanuel Dre
- Original Message -
> From: "Emmanuel Dreyfus"
> To: "Krutika Dhananjay"
> Cc: "Emmanuel Dreyfus" , "Gluster Devel"
>
> Sent: Friday, December 5, 2014 4:42:59 PM
> Subject: Re: [Gluster-devel] question on glustershd
> On Fri, Dec 05, 2014 at 04:28:49AM -0500, Krutika Dhananjay wrote:
On Fri, Dec 05, 2014 at 04:28:49AM -0500, Krutika Dhananjay wrote:
> Here's the patch I was talking about: http://review.gluster.org/#/c/9240/1
Unfortunately it does not fix entry-self-heal.t which still fails at the
same place. I wonder if the same change should not be done also on inode
lock a
With the upcoming data compliance features in GlusterFS, a common
infrastructure[1] to support various mechanisms such as tiering, bitrot
detection etc. would prove to be helpful. Such an infrastructure extends
the current changelog design (keeping NSR in mind) and removes
constraints that limi
- Original Message -
> From: "Emmanuel Dreyfus"
> To: "Krutika Dhananjay"
> Cc: "Emmanuel Dreyfus" , "Gluster Devel"
>
> Sent: Wednesday, December 3, 2014 4:09:52 PM
> Subject: Re: [Gluster-devel] question on glustershd
> On Wed, Dec 03, 2014 at 05:31:10AM -0500, Krutika Dhananjay wrot
12 matches
Mail list logo
