On Fri, Mar 27, 2020 at 07:36:15AM -0400, Jeff Layton wrote:
> On Thu, 2020-03-26 at 10:32 -0700, Gregory Farnum wrote:
> > On Thu, Mar 26, 2020 at 9:13 AM Frank Schilder <fr...@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 <jlay...@redhat.com>
> _______________________________________________
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
