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

[Pranith Kumar Karampuri]

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


> 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