On Thu, 2020-03-26 at 10:32 -0700, Gregory Farnum
wrote:
On Thu, Mar 26, 2020 at 9:13 AM Frank Schilder
<frans(a)dtu.dk> wrote:
Dear all,
yes, this is it, quotas. In the structure A/B/ there was a quota set on A. Hence, B was
moved out of this zone and this does indeed change mv to be a cp+rm.
The obvious follow-up. What is the procedure for properly moving data as an
administrator? Do I really need to unset quotas, do the move and set quotas back again?
Ah-ha, this is a difference between the userspace and kernel clients.
:( The kernel client always returns EXDEV if crossing "quota realms"
(different quota roots). I'm not sure why it behaves that way as
userspace is different:
* If fhere is a quota in the target directory, and
* If the target directory's existing data, plus the file(s) being
moved, exceed the target directory's quota,
then userspace returns EXDEV/EDQUOT. This seems like the right kernel
behavior as well...
Jeff, is that a known issue for some reason? Should we make a new bug? :)
(cc'ing Luis since he wrote cafe21a4fb3075, which added this check)
In ceph_rename, we have this, which is probably what you're hitting:
/* don't allow cross-quota renames */
if ((old_dir != new_dir) &&
(!ceph_quota_is_same_realm(old_dir, new_dir)))
return -EXDEV;
That does seem to just check whether the realms are the same and doesn't
actually check the space in them.
I haven't studied this in detail, but it may be hard to ensure that we
won't exceed the quota in a race-free way. How do you ensure that
another thread doesn't do something that would exceed the quota just as
you issue the rename request?
This is fairly trivial in the userland client since it does everything
under the BCM (Big Client Mutex), but won't be in the kernel client.
Opening a bug for this won't hurt, but it may not be simple to
implement.
Ok, I gave it a harder look and it doesn't look too bad, given that
quotas are sort of "sloppy" anyway. We could just do a check that we
won't exceed quota on the destination directory. The catch is that there
may be other details to deal with too in moving an existing inode under
a different snaprealm.
You're welcome to open a tracker bug for this, but I'm not sure who will
take on that project and when.
Thanks,
--
Jeff Layton <jlayton(a)redhat.com>