Closed axet closed 6 months ago
You can use the --max-cores
or -m
option and set it to 1.
I tried. It keep scanning in random order.
Please try the option and feel free to reopen this if you think it's not working correctly.
Here is no "reopen" issue option for me. I like first version of github much better then current one.
About the issue. I did test '-m 1' option before opening the issue. And test it again, same results:
When drive scanning, current folder jumping from one folder to original folder and back and forth. Like that:
/media/admin/1TB/Games... /media/admin/1TB/Soft... /media/admin/1TB/Games...
etc... It looks like it does it in random order, which can cause slowdown, since folder reading is not done in sequential order.
gdu 5.22.0-1+b1
If you need strictly sequential scanning, isn't ncdu better for you use case then?
Do you actually had in mind that gdu would be SSD only project? If so, then you are right. ncdu is where I should go.
But, since I'm missing background deletion in booth projects ncdu and gdu first project implementing this would be a project I want to stay with... It is much easier to implement multithreading / background tasks in go. And I assume this project would implement it first. (I tried to make it work for ncdu but code base is too hard to manage).
I do not like idea to make / keep this project as SSD only.
Yes, I plan to implement background deletion soon (this month hopefully). In that case it makes sense to improve Gdu to work better on HDDs as well.
Thanks! Here is a field report:
axet@axet-desktop:/media/axet/1TB$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
axet@axet-desktop:/media/axet/1TB$ time gdu
real 23m34,345s
user 1m50,510s
sys 1m48,378s
axet@axet-desktop:/media/axet/1TB$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
axet@axet-desktop:/media/axet/1TB$ time gdu -m 1
real 15m46,976s
user 1m7,590s
sys 1m21,093s
axet@axet-desktop:/media/axet/1TB$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
axet@axet-desktop:/media/axet/1TB$ time gdu --sequential
real 8m34,558s
user 0m43,872s
sys 1m6,693s
I suggest to add automatic detection of underlying device using /sys files:
cat /sys/devices/virtual/block/zram0/queue/rotational
1 - for hdd 0 - for ssd
additional option maybe required for manual mode: --parallel
Thank you!
gdu scanning folders in parallel, which is good for SSD, but can slow down scan progress for HDD. Can gdu detect device type (by reading /sys/block/nvme0n1/queue/rotational of current FS) or has a '-s|--sequential' flag?