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
