Hi!
I see the following commit is queued for the kernel cephfs client:
commit e2311baa73a883eb8501c895cc817d3c96c3b896
Author: Yan, Zheng <zyan@xxxxxxxxxx>
Date: Sun Apr 8 09:54:39 2018 +0800
ceph: check if mds create snaprealm when setting quota
If mds does not, return -EOPNOTSUPP.
[ This is related with http://tracker.ceph.com/issues/23491 ]
However, I'm not sure it is doing the right thing (although I confess
I'm not sure either what the right thing would be...)
This commit is doing 2 things:
1) it returns an error if a user tries to set quotas and the MDS doesn't
support it (using the new snaprealm method)
2) it forbids reading the ceph.quota.* xattrs, even if they're set
Regarding 1), it's a change in behaviour from previous kernels -- older
kernels allow these attributes to be set (but not read!), even if they
don't really support quotas. Also, the error that is returned
(-EOPNOTSUPP) is a bit misleading as the xattr is actually set in the
directory.
Regarding 2), it's a bit artificial to forbid the user to get these
attributes as we do actually have them available.
I understand the rational behind this patch, but since quotas won't be
enforced anyway in this scenario, is there really any value added with
this patch?
I would suggest 2 alternatives:
1. check cluster version and return the error in setxattr if version <
Mimic (but maybe still allow reading the xattrs?)
2. do nothing -- if we're using a cluster that does not support quotas
anyway, maybe there's no point in having these different behaviours
for old and new clients.
Thoughts?
Cheers,
--
Luis
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
