dysk stalls ~10s on Arch Linux with Btrfs since kernel 6.16.4

[neurorune]

On Arch Linux with Btrfs, dysk takes about 10 seconds before printing any output.
This affects all commands that actually enumerate mounts, e.g.:

time dysk -c fs+type+size+used
time dysk -a

…but not dysk --help, which is instant.
The delay started suddenly after upgrading from kernel 6.16.3 → 6.16.4.
It persists in 6.16.6. It happens with both dysk 3.0.0 and 3.1.0, so it seems kernel-related rather than a dysk version change.

Environment

• Distro: Arch Linux
• dysk: 3.0.0-1 and 3.1.0-1 (both tested)
• Kernel: 6.16.6-arch1-1 (regression appears between 6.16.3 and 6.16.4)
• Filesystem: Btrfs root with quotas enabled, multiple subvolumes (@, @home, @log, @pkg)
• systemd: 257.9-1

Steps to reproduce

1. On Arch with Btrfs and kernel ≥ 6.16.4, run:
   time dysk -c fs+type+size+used
2. Observe ~10 second stall before output.

Expected behavior

Output should be displayed instantly, as it was before kernel 6.16.4.

Actual behavior

Consistent ~10s delay, even with filters or --remote-stats=no.

Notes

- dysk --help is instant (so startup overhead is not the issue).
- df -h and lsblk remain instant.
- Disabling quotas (sudo btrfs quota disable /) may help, but not confirmed.
- Possibly due to how dysk probes Btrfs mounts via statfs/statvfs.
- This regression only appeared after the kernel update, but affects dysk specifically.

**Repro commands / timings**
$ time dysk -c fs+type+size+used
┌──────────────┬─────┬────┬────┐
│  filesystem  │type │size│used│
├──────────────┼─────┼────┼────┤
│/dev/nvme0n1p2│btrfs│511G│ 49G│
│/dev/nvme0n1p1│vfat │1.1G│280M│
└──────────────┴─────┴────┴────┘

real    0m10.188s
user    0m0.000s
sys     0m0.010s

$ time df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  476G   45G  431G  10% /

real    0m0.007s
user    0m0.003s
sys     0m0.004s

[Canop]

I don't really have a spare computer on which to install Arch linux atm. Can you locate more precisely the problem (probably in lfs-core) ?

[neurorune]

I don't really have a spare computer on which to install Arch linux atm. Can you locate more precisely the problem (probably in lfs-core) ?

I'll look into it after my exams. It's not only dysk I've also tried with duf. Same issue. Takes exactly 10s. So it might be some kernal issue i suppose? IDK.

[atoerien]

Just randomly clicked on this issue. I'm also on Arch, with btrfs root and kernel 6.17.3-zen2-1-zen, but dysk runs instantly for me. I don't have btrfs quotas enabled though so that might be the cause.

@anime-in-the-world if this is still an issue, maybe try strace -t dysk and see if it's hanging at some particular system call?

[0ther0ne]

same here:

Arch with btrfs (no quotas) and I dont have this issue

[Canop]

Is this problem still present with dysk 3.6.0 ?