Hi Brian! What tracker version is this?
On Thu, Nov 30, 2017 at 3:55 AM, Brian J. Murrell <br...@interlinx.bc.ca> wrote: > Is it just because /home/brian/Pictures is on an NFS server that > tracker just loops, constantly crawling it? > > 29 Nov 2017, 20:04:04: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:10:14: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:16:32: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:22:38: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:29:01: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:35:16: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:41:30: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:48:59: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 20:55:06: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 21:01:34: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 21:07:52: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 21:14:06: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 21:21:32: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 21:29:10: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > 29 Nov 2017, 21:36:35: 1% File System - Crawling recursively > directory 'file:///home/brian/Pictures' > > Is there really nothing better we can do except just constantly crawl > NFS shares? Is FAM no longer used? We don't constantly crawl anything, at least on purpose :). Tracker does no special treatment of NFS mounts, and fortunately it seems your setup avoids all the scary file locking issues with the db file. In the case there is no monitoring (disabled, run out of handles, ...) tracker-miner-fs would simply crawl it once on startup to check mtimes and reindex the content updated since the last index. And as it's been pointed out, Tracker uses glib file monitors, which have a FAM implementation. However, the limits are checked on Tracker by looking up the file monitor created on $HOME. That may result on Tracker thinking it's got a lot more handles available than what FAM can offer. I don't know if it's related to this bug or not. Back to why it's stuck in that state... do you see cpu activity or anything in logs from tracker-miner-fs or tracker-store? if you do, there's maybe something tricking tracker-miner-fs into looping across the FS. If you see tracker-miner-fs sitting idle it's perhaps the NFS server is tripping and making tracker-miner-fs block on a call. Please file a bug, and we get going from there. Cheers, Carlos _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
