[Gluster-devel] Order of server-side xlators

[Anand Avati]

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 at datalab.es>
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 at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150113/d0c8755a/attachment.html>