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@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |