[Gluster-devel] Order of server-side xlators

[Xavier Hernandez]

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