GNOME Bugzilla – Bug 732347
Freezes when searching directory tree with large number of files
Last modified: 2016-11-29 10:35:04 UTC
I can't really imagine that this was not reported before, but I can't find it either. When searching in nautilus it uses a recursive search mode which is great, but when for example you have a folder containing thousands of files it still enters that folder for that search and freezing in the process. Even if the search was not started in that folder. It would therefore be beneficial if we were able to select what searchmode we would like to use, either recursive or type-ahead.
Thanks for the bug report. Allowing the user to choose between recursive and non-recursive search is a possibility, and there are even designs for that.[1] https://raw.github.com/gnome-design-team/gnome-mockups/master/nautilus/search-wires.png Do you see nautilus freezing consistently when searching? Can you provide more information about the freezes? Even if a future nautilus version lets the user choose search mode, it will still be a big problem if it freezes when a person does want to perform a recursive search. Debugging these freezes would be most beneficial in any case.
The problem is relatively easy, it was me who submitted a bug but it was discovered by a classmate of me. The problem mainly arises when we have a folder that we cannot enter because it is simply too big, nautilus needs to allocate too much memory to show that folder. Lets call it "really_big_folder" consisting of millions of files. If I was to search in the parent of that really_big_folder it would recurse into that folder too, trying to search there. I think thats just somewhat of a result of searching recursively, when folders get too big the recursing fails.. One possible solution is to give up on certain folders when they are big, thus not allocating resources to search that folder. +-parent ----> really_big_folder (millions of files) I generally think this is mainly an issue because my classmate has a folder of millions of files, but the real issue in my view is that he cannot search in parents of that really_big_folder because nautilus tries to search recursively.
Thank you for the detailed information. Can you set the version of nautilus this is happening? Is really_big_folder indexed by tracker? (You can see and change which folders are indexed on GNOME Settings: in the Search view there is a gear button that pops up a dialog.) If not indexed, does it help if it gets indexed? (It may take a while to complete the indexing process, you can check status in the command line with the "tracker-control" command.) Potentially related bugs, for reference: bug 682836 - about performance on folders with a large number of files; bug 725939 - another case of breakage in consequence of performing a recursive search, in this case over SFTP connection.
My sincere apology, I was too busy lately and therefore forget to respond. My classmate did some tests, tracker is not able to index the folder. If he tries to do so tracker-miner-fs (the process) climbs in memory usage and doesnt report real progress (stuck on 1%). When his laptop locked he was not able to relog, the computer was too heavily loaded to peform these tasks. After reboot tracker retried indexing the offending folder, again rising in memory usage and too busy to respond to user commands. When his computer locked again the logon failed again (like, it was not responsive). He ran the indexing for about 15 to 20 minutes and he did not see the completion surpass 1%. He estimated that (if tracker was on the verge of presenting 2%) it would still take 33 hours to index that offending folder. This clearly is a problem of tracker, who is too eager to do try and index that folder instead of failing because it is too big.. Moreover it feels "wrong" that tracker retries it after a relog, this could result in serious issues to endusers effectively bricking their computers. Should I report that as a bug to tracker? Back to Nautilus, he also tried searching various letters, it fails (and bricks nautilus) when the resultset would be too big. If I understand correctly (will ask him again), when the folder contains lots of files starting with an "a", and he searches for that "a" that will brick nautilus. But searching for less common patterns is less of a problem, so for example searching for an "q" if not much files have a "q" in their name. Please say so if you need more info, sadly the classmate that has the bug refuses to comment so I'll be the spokesman. I am more then willing to issue tickets or discuss with my classmate what could cause these issues.
(In reply to comment #4) > My sincere apology, I was too busy lately and therefore forget to respond. That's no problem at all, and thanks for gathering all this information. > Should I report that as a bug to tracker? Absolutely, please do it when you have the time. > Please say so if you need more info, sadly the classmate that has the bug > refuses to comment so I'll be the spokesman. I am more then willing to issue > tickets or discuss with my classmate what could cause these issues. As a bug triager I don't the only other info I'll ask is which version of nautilus your classmate uses. Hopefully a developer will take a look at this bug and ask for more info as needed. --- As the original request for an alternative to recursive search is already in the scope of bug 681871, I'm changing the summary of this bug report to track the freezes when performing a recursive search with lots of files in the search scope.
He is using Fedora 20 with Gnome 3.10. I've updated the version in the details.
Search has improved *immensely* since 3.10 and performance doesn't seem to be such an issue anymore. I noticed freezes and lags in the past and none nowadays. I am therefore closing this as obsolete, but feel free to reopen if you can reproduce the issue with a recent version of Nautilus.