Re: XFS & LVM: unexpected cp when issuing mv

Dave Chinner
2009-12-01T00:19:18Z

On Mon, Nov 30, 2009 at 02:42:20PM +0100, Michael Monnerie wrote:
> On Montag, 30. November 2009 Dave Chinner wrote:
> > > 1) why this happens
> >
> > It happens if you move from one project directory heirarchy to
> > another - rename is not allowed across project quota boundaries as
> > the moved data has to be correctly attributed to the new project.
> > Hence it causes a mv to do a copy/unlink by returning a EXDEV error
> > to the rename.
> >
> > > 2) how I can prevent this?
> >
> > You can't if you are moving from one project to another. If you
> > move within the project heirarchy, then it will be a rename as per
> > normal.
>
> Shit. So I have to turn project quotas off. I can't accept the extra
> load for a simple move, as there are tons of data. Maybe the projet code
> could be redesigned to allow a simple move? Is it that complicated?

IIRC, it was a design decision to make project quotas behave this
way. Returning EXDEV made the code to handle this very simple -
userspace already handles this error correctly and all the kernel
needs is 3 lines of code to detect differing project IDs on the
inodes and return EXDEV.

To do it without copying is definitely possible - it requires
extending the rename transaction to directly modify the project
quota id of the target inodes and the relevant dquots as well. It
becomes quite complicated because it also has to handle the cases of
source or destination not having quotas at all, the destination
not having enough space (i.e. EDQUOT), etc.

All the nasty corner cases are handled by userspace by returning
EXDEV to force it to copy rather than renaming, so the decision was
made to do the simple (if slow) thing for relatively uncommon
operation of moving data between projects.

> If I change from project to user quota - I guess the same would still
> happen?

No - the EXDEV error (and therefore the copy) is a feature of project
quotas.

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com