Hi Stefan, thank you for sharing your experience! After I read your mail I did some more testing and for me the issue is strictly related to snapshots and perfectly reproducible. However, I mad two new observations that was not clear for me until now.
First, snapshots that was created before the folders that I use to test with `du` are written, does not have any negative performance impact. Second, the metadata a client already has in cache before a snapshot is taken is not invalide after a snapshot has ben tacken and still can be used which make my executions of `du` very fast. The following order of actions should illustrate my observations: $ mkdir share/users/.snap/t1 $ mkdir share/users/.snap/t2 $ mkdir share/users/.snap/t3 $ mkdir share/users/.snap/t4 $ rsync -aH share/backup-remote-1/ share/backup-remote-2/ $ umount $ mount -t ceph ... $ du -h share/backup-remote-2/ The execution of `du` take only 2m18.720s which is reasonable. Now lets take another snapshot with an other ceph-client: $ mkdir share/users/.snap/t5 Back on our man test machine that has the cephFS still mounted: $ du -h share/backup-remote-2/ => 14.156s very fast (presumable all required date read from the client cache) umount and mount the cephFS again: $ umount $ mount -t ceph … $ du -h share/backup-remote-2/ => 20m16.984s …. 10 times slower > No solution, but good to know there are more workloads out there that hit > this issue. If there are any CephFS devs interested in investigating this > issue we are more than happy to provide more info. I also would be happy to provide more infos. Best wishes, Sebastian _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
