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

[Nithya Balachandran]

On 29 June 2018 at 13:02, 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.
>
+1

>
> 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)
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180702/9efcda7f/attachment.html>