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
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel

Reply via email to