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