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

[Raghavendra Gowdappa]

On Fri, Jun 29, 2018 at 1:02 PM, Amar Tumballi <atumball at redhat.com> wrote:

>
>
> 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.
>

I guess my previous reply was not sufficiently verbose. I agree with the
future plan. As I've discussed offline with you, the ambiguity is in
roadmap on how we arrive at that future. What this attempt is currently
maintenance. If you've an action plan/roadmap for,
* fixing current consistency issues and known performance issues
* unified performance xlator/global caching

I would be happy to discuss. It'll be helpful If we can make the discussion
concrete in terms of
* what issues we are fixing as part of maintenance and what are the issues
we are taking a call  on not fixing, but deferring for future solution.
* plans to mitigate (if any) any issues in the interim till new solution
becomes stable enough to be a replacement with current perf xlator stack.

Note that there is a growing demand for supporting DB workloads. Are we
planning to say no for these workloads till new solution is a in a state to
replace existing stack? Long ago I made a list of issues with current perf
xlator stack at [1]. We can use that as a rough reference.

[1]
https://docs.google.com/document/d/1wOsXAfhXFN0drGDTInPZXpFl2fX3La5FgkrdRksUiiw/edit?usp=sharing


> 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/20180702/e4993e08/attachment.html>