Is there is a possibility that there was a quota involved? I've seen moves between quota zones to cause a copy then delete. -- Adam On Thu, Mar 26, 2020 at 9:14 AM Gregory Farnum <gfarnum@redhat.com> wrote:
On Thu, Mar 26, 2020 at 5:49 AM Frank Schilder <frans@dtu.dk> wrote:
Some time ago I made a surprising observation. I reorganised a directory structure and needed to move a folder one level up with a command like
mv A/B/ B
B contained something like 9TB in very large files. To my surprise, this command didn't return for a couple of minutes and I started to look what was going on. What I discovered was, that the mv command actually performed a full copy with a subsequent remove. I had to wait for several hours for the move to complete.
I tried to reproduce this today to collect further information. However, this behaviour seems not reproducible. No matter what I try, mv completes almost instantly.
I was running the original mv on mimic 13.2.2 and retried now with mimic 13.2.8. In addition, there was an OS upgrade from Centos 7.6 to 7.7. I'm using the kernel-ml versions (5.xxx). Only one cephfs mount was present at all times.
My questions are:
1) Was there a change from 13.2.2 to 13.2.8 explaining this?
No.
2) Are there (rare) conditions under which an mv on cephfs becomes a cp+rm?
Not as part of CephFS.
3) Am I seeing ghosts?
The only way I can imagine this happening is if you had separate CephFS mounts for cephfs/A/B and cephfs/ and you did the move between them, instead of within the cephfs/ mount. :/ -Greg
Thanks for clues and best regards,
================= Frank Schilder AIT Risø Campus Bygning 109, rum S14 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io