On Thu, 2020-03-26 at 10:32 -0700, Gregory Farnum wrote:
> On Thu, Mar 26, 2020 at 9:13 AM Frank Schilder <frans@xxxxxx> 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.
--
Jeff Layton <jlayton@xxxxxxxxxx>
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
