Sent: Wednesday, June 1, 2016 11:57:12 AM
Subject: Re: [Gluster-devel] dht mkdir preop check, afr and
(non-)readable afr subvols
Oops, you are right. For entry operations the current
version of the
parent directory is not checked, just
t; , "Raghavendra G" <
>>> raghaven...@gluster.com>
>>> Cc: "Gluster Devel"
>>> Sent: Wednesday, June 1, 2016 11:57:12 AM
>>> Subject: Re: [Gluster-devel] dht mkdir preop check, afr and
>>> (non-)readable afr subvols
>>>
&g
Hi,
On 01/06/16 08:53, Raghavendra Gowdappa wrote:
- Original Message -
From: "Xavier Hernandez"
To: "Pranith Kumar Karampuri" , "Raghavendra G"
Cc: "Gluster Devel"
Sent: Wednesday, June 1, 2016 11:57:12 AM
Subject: Re: [Gluster-de
- Original Message -
> From: "Xavier Hernandez"
> To: "Pranith Kumar Karampuri" , "Raghavendra G"
>
> Cc: "Gluster Devel"
> Sent: Wednesday, June 1, 2016 11:57:12 AM
> Subject: Re: [Gluster-devel] dht mkdir preop check, afr
Oops, you are right. For entry operations the current version of the
parent directory is not checked, just to avoid this problem.
This means that mkdir will be sent to all alive subvolumes. However it
still selects the group of answers that have a minimum quorum equal or
greater than #bricks -
Xavi,
But if we keep winding only to good subvolumes, there is a case
where bad subvolumes will never catch up right? i.e. if we keep creating
files in same directory and everytime self-heal completes there are more
entries mounts would have created on the good subvolumes alone. I think I
m
I've filed a bug at [1] to track issue in afr.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341429
On Tue, May 31, 2016 at 2:17 PM, Raghavendra G
wrote:
>
>
> On Tue, May 31, 2016 at 12:37 PM, Xavier Hernandez
> wrote:
>
>> Hi,
>>
>> On 31/05/16 07:05, Raghavendra Gowdappa wrote:
>>
>>> +g
On Tue, May 31, 2016 at 12:37 PM, Xavier Hernandez
wrote:
> Hi,
>
> On 31/05/16 07:05, Raghavendra Gowdappa wrote:
>
>> +gluster-devel, +Xavi
>>
>> Hi all,
>>
>> The context is [1], where bricks do pre-operation checks before doing a
>> fop and proceed with fop only if pre-op check is successful.
Just checked ec code. Looks okay. All entry fops are also updating metadata
and data part of the xattr.
On Tue, May 31, 2016 at 12:37 PM, Xavier Hernandez
wrote:
> Hi,
>
> On 31/05/16 07:05, Raghavendra Gowdappa wrote:
>
>> +gluster-devel, +Xavi
>>
>> Hi all,
>>
>> The context is [1], where bric
Hi,
On 31/05/16 07:05, Raghavendra Gowdappa wrote:
+gluster-devel, +Xavi
Hi all,
The context is [1], where bricks do pre-operation checks before doing a fop and
proceed with fop only if pre-op check is successful.
@Xavi,
We need your inputs on behavior of EC subvolumes as well.
If I under
+gluster-devel, +Xavi
Hi all,
The context is [1], where bricks do pre-operation checks before doing a fop and
proceed with fop only if pre-op check is successful.
@Xavi,
We need your inputs on behavior of EC subvolumes as well.
[1] http://review.gluster.org/13885
regards,
Raghavendra
-
11 matches
Mail list logo
