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(a)redhat.com> wrote:
On Thu, Mar 26, 2020 at 5:49 AM Frank Schilder <frans(a)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(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io