Re: Order of server-side xlators

[Anand Avati <avati@xxxxxxxxxxx>]

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)

Thanks

On Mon Jan 12 2015 at 5:02:59 AM Xavier Hernandez <xhernandez@xxxxxxxxxx> wrote:

Hi,

looking at the server-side xlator stack created on a generic volume with
quota enabled, I see the following xlators:

     posix
     changelog
     access-control
     locks
     io-threads
     barrier
     index
     marker
     quota
     io-stats
     server

The question is why access-control and quota are in this relative order.
It would seem more logical to me to be in the reverse order because if
an operation is not permitted, it's irrelevant if there is enough quota
to do it or not: gluster should return EPERM or EACCES instead of EDQUOT.

Also, index and marker can operate on requests that can be later denied
by access-control, having to undo the work done in that case. Wouldn't
it be better to use index and marker after having validated all
permissions of the request ?

I'm not very familiarized with these xlators, so maybe I'm missing an
important detail.

Thanks,

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