GNOME Bugzilla – Bug 762194
Initial filesystem check runs at full throttle while on battery
Last modified: 2021-05-26 22:26:29 UTC
Subject says it. I run 'tracker-preferences', and 'Enable on battery' is not checked. Yet, when I turn on my machine on battery, tracker-miner-fs eats tons of CPU and stroage bandwdith. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tracker depends on: ii dbus 1.10.6-1 ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii libc6 2.21-7 ii libexempi3 2.2.2-2+b1 ii libglib2.0-0 2.46.2-3 ii libtagc0 1.9.1-2.4 ii libtracker-control-1.0-0 1.6.1-2 ii libtracker-sparql-1.0-0 1.6.1-2 ii shared-mime-info 1.5-2 Versions of packages tracker recommends: ii tracker-gui 1.6.1-2 ii tracker-miner-fs 1.6.1-2 tracker suggests no packages. -- no debconf information
Uhm, well... the tracker-preferences checkbutton label is not too definite/accurate, the gsetting has a more accurate "index-on-battery" name, "index" being the key here. What Tracker refrains from with that setting turned on is attempting to extract information from any file, but otherwise it will still get hold of filesystem notifications, just so it can catch up with the accumulated changes as soon as we've got power. As such, it still attempts to recurse through the indexed folders, and set up file monitors ASAP, the I/O you see basically comes down to the opendir(), readdir() and inotify_add_watch() syscalls. And I'm uneasy about postponing this until there's power, Tracker can indeed find out the changes that were done to the filesystem in the mean time, but adding monitors is currently racy (monitors are added after the directory is iterated), and it seems a lot more likely when you run to plug the laptop in order to let that copy finish. I guess fixing this race condition could help us do that. That said, this is a one-shot operation, it must be done at some point, and we can't do much better with inotify... If this involves noticeable I/O or CPU (eg. more than a few seconds), it comes down to the amount of directories to recurse into, perhaps you could trim down the inspected tree by adding directories to be ignored in the "ignored content" tab in the mean time.
thanks for the explanation; dropping from taret list
Retitling
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.