Revisit "search-file" usage as the first "search-file" transaction after boot is costly
Forked from #2254 (comment 1815988)
When we do a PackageKit.search-file ('^/usr/share/applications/org.gnome.Software.desktop$')
, the following happens in debian ( APT ). I assume something similar happens in dnf
matches = None
dir = opendir ("/var/lib/dpkg/info")
foreach file in dir:
do
if not filename.ends_with(".list");
continue
match = grep "^/usr/share/applications/org.gnome.Software.desktop$" file
if match:
matches.append(file)
done
Here is the actual installed file stats in /var/lib/dpkg/info/
dir on my debian unstable:
[root@linux:/var/lib/dpkg/info]# ls | wc -l
19796
[root@linux:/var/lib/dpkg/info]# ls *.list | wc -l
5932
[root@linux:/var/lib/dpkg/info]# du -sh .
180M .
So, even if we reduce the number of search-file
transactions from 72 ( in my system ) to 1 ( with !1752 (merged)), the single search-file
transaction could still take a long time sometimes. This normal happens the first time after boot, when the files are physically read from disk ( and whenever the fs buffer cache is replaced / swapped to disk ). Also, when running the single search-file
transaction, if the disk is busy ( e.g. file copy operations in nautilus
), this delay will be much more.
Below is one such single search-file
transaction, when there was a 5GB file copy operation in progress in nautilus
search-file transaction /83753_eeccabee from uid 1000 finished with success after 180651ms
The transaction took 3 minutes.
I think this is the same issue which I originally reported in the issue description for the dnf
backend.
search-file transaction /1687_cdabeabd from uid 1000 finished with success after 54102ms
search-file transaction /1688_cdabcabd from uid 1000 finished with success after 12ms
search-file transaction /1689_cdaaaabd from uid 1000 finished with success after 23ms
search-file transaction /1690_cdabbabd from uid 1000 finished with success after 21ms
where the first transaction took a long time.
Questions:
I'm sure our intention is not to actually do a grep "pattern" /var/lib/dpkg/info
- What info do we actually need in the refine process ?
- Is there a way to get the needed info without
search-file
transaction ( e.g fromget-details <pkg>
etc ) ?