The **btrfs check** command output doesn't mention how many files are fragmented like **e4defrag -c** or **e2fsck** with **ext4** filesystems. What command can give the number of fragmented files on a **whole Btrfs filesystem** ?

If I kill a running e4defrag , is there a risk of data loss/corruption? Is there a safe way to interrupt it? For example: running e4defrag on large partition (such as the root directory) or large file (such as a squashfs system image file) is very slow, so sometimes, stopping/killing e4defrag before it is done is needed, but I'm not sure whether killing it (by sending either of SIGINT,SIGTERM,SIGKILL, etc. to it) e4defrag is safe? I'm running Debian Stretch and the filesystem is ext4. My kernel version:4.14.13 My e2fsprogs version:1.43.4-2

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 .