[Gluster-devel] Storing list of dentries of children in parent inode

[Amar Tumballi]

On Fri, Jun 29, 2018 at 12:25 PM, Vijay Bellur <vbellur at redhat.com> wrote:

>
>
> On Wed, Jun 27, 2018 at 10:15 PM Raghavendra Gowdappa <rgowdapp at redhat.com>
> wrote:
>
>> All,
>>
>> There is a requirement in write-behind where during readdirp we may have
>> to invalidate iatts/stats of some of the children of the directory [1]. For
>> lack of better alternatives I added a dentry list to parent inode which
>> contains all children that've been linked (through lookup or readdirp on
>> directory). I myself am not too comfortable with this solution as it might
>> eat up significant memory for large directories.
>>
>> Thoughts?
>>
>
>
> Reading [2] makes me wonder if write-behind is the appropriate place for
> this change. Shouldn't md-cache be made aware of inode generations or
> something similar?
>
>
Thanks for the pointers Vijay. But, now what happens if user keeps
write-behind and turns off md-cache? (like virt profile and block profile).

Raghavendra, while this patch fixes the problem specific to the usecase,
all these changes break the boundary of translators, which were supposed to
deal with just 1 fop (or one feature).

It makes sense for us to move towards a global 'caching' xlator which can
give better performance,  and has visibility to all the information about
the file, and all fop. That will reduce all this complexity of what should
be done for certain specific cases, type of problems.

Also, is there any performance numbers possible with this patch and without
this patch in regular readdirp operations ?

Regards,
Amar

Thanks,
> Vijay
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1512691#c18
>
>
>
>>
>> [1] https://review.gluster.org/20413
>>
>> regards,
>> Raghavendra
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180629/45f3ef6c/attachment.html>