Since we're on the subject of minimizing STAT calls, there was talk in the small-file perf meeting about moving the md-cache translator into the server just before the POSIX translator so that all the stat and getxattr calls, etc. could be intercepted. This would be consistent with not needing to put access-control down near POSIX translator. Also we had discussed introducing negative caching (we could call llistxattr() first) to the md-cache translator so that we would not constantly ask brick fs for non-existent xattrs. ----- Original Message ----- > From: "Xavier Hernandez" <xhernandez@xxxxxxxxxx> > To: "Anand Avati" <avati@xxxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Tuesday, January 13, 2015 4:18:15 AM > Subject: Re: Order of server-side xlators > > On 01/13/2015 05:45 AM, Anand Avati wrote: > > Valid questions. access-control had to be as close to posix as possible > > in its first implementation (to minimize the cost of the STAT calls > > originated by it), but since the introduction of posix-acl there are no > > extra STAT calls, and given the later introduction of quota, it > > certainly makes sense to have access-control/posix-acl closer to > > protocol/server. Some general constraints to consider while deciding the > > order: > > > > - keep io-stats as close to protocol/server as possible > > - keep io-threads as close to storage/posix as possible > > - any xlator which performs direct filesystem operations (with system > > calls, not STACK_WIND) are better placed between io-threads and posix to > > keep epoll thread nonblocking (e.g changelog) > > > > Based on these constraints and the requirements of each xlator, what do > you think about this order: > > posix > changelog (needs FS access) > index (needs FS access) > marker (needs FS access) > io-threads > barrier (just above io-threads as per documentation (*)) > quota > access-control > locks > io-stats > server > > (*) I'm not sure of the requirements/dependencies of barrier xlator. > > Do you think this order makes sense and it would be better ? > > Xavi > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
