Tracker takes very long time to index system, provides no obvious status information

Confirming, would be nice to inform the user of what is going on and to give him the option to stop the indexing if he wants to

My laptop has been running trackerd for the last 4 days or so. I still hasn't stopped indexing.

Core Duo 2GHz, 1GB RAM, 72GB home directory being indexed.

But it has filled up my disk during the last day. I have a 72GB home directory, of which 3.1GB is tracker's incomplete index of it, and is therefore full. To let it get this far I deleted a few of my video files. Of course, each time I delete some files, trackerd takes up some more space and fills the disk again...

Because there's no indication of progress, I don't have any idea how much space it will need in total for the index. Is it 10% on top of my data requirements? 25%? Do I need to free up many more gigabytes? Do I need to buy a bigger disk?

I only know that whenever I free up some space, it gets used up quickly by trackerd. Eventually I have other things to do than looking for large files to delete.

That means I have no way to decide if trackerd is worth having, or if it will use too much space for its index and I should delete it.

Now I'm thinking, apart from the way it makes the desktop unusably slow (presumably this will be fixed eventually), and the battery use, and the need to re-scan my home directory (for hours) each time I reboot, now I'm thinking it also uses more disk space than I'm willing to spend on it.

Disk space required is hard to estimate

AFter indexing is finished the hashtable is optimised (which means its copied temporarily into a fresh one to eliminate fragmentation)

after fragmentation is eliminated size is typically 5-10% of unfragmented (depends on amount of fragmentation)

of disk its approx 10%-20% of indexable content (eg text files, source files, docs etc). Images, audio, binary and Video files have virtually no effect oin size of index

we are replacing the hashtable with sqlite which does not suffer fragmentation issues and who's databases have a lot smaller foot print on disk (slower search speed but more scalable when indexing)

we hope to have these improvements in time for tribe 5

Retargeting as this won't make Beta release. Jamie is working on this, and it might be finished for tracker 0.6.4.

tracker (0.6.4-1ubuntu1) hardy; urgency=low

  * Merge with Debian, remaining Ubuntu changes:
    - debian/control:
      + Addhere to DebianMaintainerField spec.
      + Do not build-depend on universe dependencies:
        libunac1-dev, libqdbm-dev.
      + tracker depends on o3read instead of recommend it, so we have
        OOo indexing by default.
    - debian/rules:
      + Enable sqlite external db instead of qdbm.
    - debian/patches/02_no_kde_autostart.patch:
      + Do not autostart trackerd in Kde, as they have strigi.
    - debian/patches/03_no_initial_index_in_battery.patch:
      + Do not run the initial index if running on battery.
        Patch taken from upstream SVN, revision 1075:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1075
    - debian/patches/04_fix_crash_index_name_is_null.patch:
      + Fix a crash when index name is null during merging.
        Patch taken from upstream SVN, revision 1076:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1076
    - debian/patches/05_typo_audio_track_peak_gain_tag.patch:
      + Fix a typo in a tag metadata. LP: #145359
        Patch taken from upstream SVN, revision 1077:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1077
    - debian/patches/06_trackerd_infinite_loop.patch:
      + Fix an infinite loop in trackerd if a second instance is
        launched. Patch taken from upstream SVN, revision 1079:
        http://svn.gnome.org/viewvc/tracker?view=revision&revision=1079

  * Bugs fixed in the new release:
    - LP: #130935. Added a notification area tool displaying trackerd's
      status, and allowing to search from there.
    - LP: #138331: prevent hangs which stopped tracker quitting smoothly.
    - LP: #147756: Fixed memory leaks.
    - LP: #159807: Stop indexing if disk is full.
    - LP: #164148: Unsafe tempfile usage.
    - LP: #148520: Check for overlapping watch dirs
    - LP: #132463: Always show full path of files in tracker-search-tool.
    - LP: #133402: Do not repeat 'Preferences' in the preferences title.
    - LP: #164412: Limit log size to 10MB.
    - LP: #150814: Detect and prevent database corruption.
    - LP: #160262: Fix evolution email opening for the deskbar handlers.
    - LP: #150030: Show applications in search results.

 -- Emilio Pozuelo Monfort <email address hidden> Fri, 14 Dec 2007 01:16:26 +0100