On Fri, Jun 29, 2018 at 1:02 PM, Amar Tumballi <[email protected]> wrote:
> > > On Fri, Jun 29, 2018 at 12:25 PM, Vijay Bellur <[email protected]> wrote: > >> >> >> On Wed, Jun 27, 2018 at 10:15 PM Raghavendra Gowdappa < >> [email protected]> 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). > 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, > 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 >>> [email protected] >>> http://lists.gluster.org/mailman/listinfo/gluster-devel >> >> >> _______________________________________________ >> Gluster-devel mailing list >> [email protected] >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > > > -- > Amar Tumballi (amarts) >
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
