[Tendrl-devel] Impact on tendrl due to BZ 1404110 - POSIX_SAME_GFID event seen for .trashcan folder and .trashcan/internal_op ?

Nithya Balachandran nbalacha at redhat.com
Thu Dec 15 03:47:07 UTC 2016


On 14 December 2016 at 20:44, Atin Mukherjee <amukherj at redhat.com> wrote:

>
>
> On Wed, Dec 14, 2016 at 7:25 PM, Pranith Kumar Karampuri <
> pkarampu at redhat.com> wrote:
>
>>
>>
>> On Wed, Dec 14, 2016 at 7:16 PM, Atin Mukherjee <amukherj at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 14, 2016 at 7:03 PM, Nithya Balachandran <
>>> nbalacha at redhat.com> wrote:
>>>
>>>> I think this shows up because the internal dirs already exist on the
>>>> brick not because they have the same gfid. I've seen the posix log message
>>>> every time a brick is restarted.
>>>>
>>>> This is something we should ignore for these dirs.
>>>>
>>>
>>>                          gf_event (EVENT_POSIX_SAME_GFID,
>>> "gfid=%s;path=%s;"
>>>                                   "newpath=%s;brick=%s:%s",
>>>
>>>                                   uuid_utoa
>>> (uuid_req),
>>>                                   gfid_path ? gfid_path : "<NULL>",
>>> loc->path,
>>>                                   priv->hostname, priv->base_path);
>>>
>>> And I guess we'd be also passing the directory name in this event, so
>>> tendrl can check if the trashcan directory is there in the parameter list,
>>> then ignore the event ?
>>>
>>
>> Anoop is already working to remove trash directory appearing here, so it
>> is better to not have this extra filtering implemented in tendrl IMO
>>
>
> So we should fix it and not defer?
>
>
I think so. It should be fairly simple - just check if the dir you are
trying to create already exists with the same gfid.

Regards,
Nithya

>
>>
>>> IMO, in occurrence of this event, UI at best can notify an admin and
>>> then a corrective set of actions need to be taken.
>>>
>>
>> Yes.
>>
>>
>>>
>>>
>>>> Regards,
>>>> Nithya
>>>>
>>>> On 14 December 2016 at 18:57, Pranith Kumar Karampuri <
>>>> pkarampu at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 14, 2016 at 6:51 PM, Atin Mukherjee <amukherj at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 14, 2016 at 6:49 PM, sankarshan <sankarshan at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 14 December 2016 at 18:40, Atin Mukherjee <amukherj at redhat.com>
>>>>>>> wrote:
>>>>>>> > We have identified an issue related to POSIX_SAME_GFID event where
>>>>>>> this
>>>>>>> > unwanted event is seen for .trashcan and .trashcan/internal_op
>>>>>>> folders.
>>>>>>> > This event is meant to emitted from posix stack from Gluster in
>>>>>>> mkdir
>>>>>>> > codepath in case an existing directory with the new mkdir request
>>>>>>> shares
>>>>>>> > the same GFID which can lead to inconsistencies. This particular
>>>>>>> case is
>>>>>>> > observed when a brick stop and start is performed. Now the
>>>>>>> question I've
>>>>>>> > here is what tendrl is supposed to do once it sees a
>>>>>>> POSIX_SAME_GFID. Will
>>>>>>> > there be any reactive action taken against it or it just gets
>>>>>>> notified to
>>>>>>> > the admin?
>>>>>>> >
>>>>>>> > Could you please assess this case w.r.t how does this impact
>>>>>>> tendrl and if
>>>>>>> > we can live with it?
>>>>>>>
>>>>>>> Alright. So, I'd like to propose this approach. What would a Gluster
>>>>>>> storage admin do (in absence of Tendrl) in order to deal with this
>>>>>>> notification and the event which caused it? Are there specific
>>>>>>> sequence of steps which (s)he would perform and thus additional new
>>>>>>> flows need to be built into Tendrl? Or, is this a (benign?) event
>>>>>>> which is more of warning/information and no further (remedial) action
>>>>>>> is required by the admin?
>>>>>>>
>>>>>>
>>>>>> +Pranith - could you chime in with your thoughts here?
>>>>>>
>>>>>
>>>>> Storage admin should try to fix the directory gfids to make sure two
>>>>> directories won't have same gfid. This log/event is added to help people
>>>>> who want to fix the directory gfids by giving the two directory path names.
>>>>> So if I am a storage admin and I see this issue I will need to immediately
>>>>> call redhat support and give these events/logs which will make life easier
>>>>> for GSS to fix the issue.
>>>>>
>>>>> I am also adding Raghavendra/Nithya.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Tendrl-devel mailing list
>>>>>>> Tendrl-devel at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/tendrl-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> ~ Atin (atinm)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Pranith
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> ~ Atin (atinm)
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
>
> --
>
> ~ Atin (atinm)
>



More information about the Tendrl-devel mailing list