Open Dialga opened 1 year ago
Hum. That's curious. Any idea of what's the filesystem which causes the problem ?
Can you try dysk --remote-stats no
?
Hi, I've just tried that and same result.
I don't know which filesystem you can easily unmount but trying without some of them would probably tell us where the problem is. Or I'll have to make a special version with time analysis.
Interestingly I've just tried with dfrs --total
and that also took some 1m25s to process, so disks that are not being displayed are also being calculated in dysk. Will continue to narrow down.
disks that are not being displayed are also being calculated in dysk
This eases decoupling filtering logic and data gathering logic (they're in different crates btw) and the only cases of slow "computing" I had until now were the remote filesystems. I'll reconsider this part of the architecture depending on your findings.
I've found the offending line causing trouble in my fstab, which I use to automount an external hdd that's not currently connected:
UUID=XXX /mnt/XXX ntfs3 rw,relatime,iocharset=utf8,prealloc,group,owner,user,uid=1000,gid=1000,auto,nofail,acl,X-mount.mkdir,X-mount.owner=me,X-mount.group=me,x-systemd.automount 0 0
It appears that running dysk triggers a systemd job to run, but not for dfrs.
$ systemctl list-jobs
No jobs running.
$ dysk
^C
$ systemctl list-jobs
JOB UNIT TYPE STATE
1000 mnt-XXX.mount start waiting
1000 dev-disk-by\x2duuid-XXX.device start running
$ dfrs
...
$ systemctl list-jobs
No jobs running.
A further search brought me to https://www.freedesktop.org/software/systemd/man/systemd.mount.html#x-systemd.device-timeout= to which I configured to 1 second, and now dysk runs in 1s. So that's the root cause of this issue.
Thanks for the investigation.
With this, I should be able to try reproduce the problem and look for workarounds.
I changed the issue title to ease management. Feel free to adjust it if you want but try to keep it as specific as possible.
I have the same issue:
% time /bin/dysk > /dev/null
/bin/dysk > /dev/null 0.01s user 0.00s system 0% cpu 5.044 total
% time /bin/df > /dev/null
/bin/df > /dev/null 0.00s user 0.00s system 80% cpu 0.007 total
Maybe dysk is doing things in series rather than parallel... it's a big jump from 0.00 to 5.
I have 5 x-systemd.device-timeout
entries in /etc/fstab
, each =200ms
.
So I'm not sure where the 5 seconds is coming from.
(Thanks @Dialga for clueing me into dfrs
)
dysk, and it's previous incarnation always takes ~1m30 seconds to load on my system, whereas the alternative dfrs shows disk usage immediately.