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.
(Sorry for the delay replying.)
So, I did a bit of digging (it has been a while since last time I looked
at this code) and the reason for this -EXDEV was to actually mimic the
code in the userspace client code (see bbfeaaea53f1 ("client: Forbid
moving files across quota trees")).
In the meantime, it seems like this restriction has been removed from the
userspace client in commit b8954e5734b3 ("client: optimize rename
operation under different quota root"). I'll try to have a look at this
in the next few days and see how this could be included in the kernel
client as well.
Cheers,
--
Luis
>
> 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(a)redhat.com>
> _______________________________________________
> ceph-users mailing list -- ceph-users(a)ceph.io
> To unsubscribe send an email to ceph-users-leave(a)ceph.io