How can lsof -p $pid be stalling when ls /proc/$pid/fd is not?

I have a situation where I observe that BackupPC stalls for a particular host. This host runs Debian 10 (and has e.g. Docker installed). During that situation, two rsync-related processes are running on that host (parent sudo /usr/bin/rsync --server ... and child /usr/bin/rsync --server ...). When I try to find out which file rsync is currently handling (i.e. where it stalls) by issuing lsof -p $child_pid, this also stalls (i.e. it apparently never returns but can be stopped e.g. with Ctrl-C). ls /proc/$child_pid/fs works fine at the same time (and returns only 4 fds). So perhaps this is close to the root cause why rsync is stalling. How can it be the case that lsof -p is stalling esp. when ls /proc/$child_pid/fd is not? Should it not always come back with an (almost) immediate answer? And how can I further diagnose the situation (as well as then resolve it)? **UPDATE** I am now checking for fragmentation in ext4 file systems on that host. This also takes a long time ... time e4defrag -v -c $(df -t ext4 | tail -n +2 | awk '{print $1}') **UPDATE** By now it looks as if e4defrag -v -c is stuck; its last output reads "/media/cdrom0" File is not regular file. The host is in fact a Proxmox VM, so could the issue perhaps be related to its virtual CD-ROM? This seems unlikely though, because df /media/cdrom0 indicates it is mounted on /, and if I am not mistaken e4defrag is already past this file system and now into /var. Perhaps /var (size 23G) is so heavily fragmented that a long duration is normal or perhaps e4defrag hits some limitations .