On Fri, Jun 29, 2018 at 1:02 PM, Amar Tumballi <atumball@xxxxxxxxxx> wrote:
On Fri, Jun 29, 2018 at 12:25 PM, Vijay Bellur <vbellur@xxxxxxxxxx> wrote:On Wed, Jun 27, 2018 at 10:15 PM Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:All,Thoughts?
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.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,AmarThanks,Vijay_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel --Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
