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).
We have to fix bugs for existing users :).
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 ?
Will try to get when I've free cycles.
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
