Content-type: text/html
mu-index understands Maildirs as defined by Dan Bernstein for qmail. It also understands recursive Maildirs (Maildirs within Maildirs), and the VFAT-version of Maildir, as used by Tinymail/Modest.
The first run of mu-index can take some time; on the author's 4-year old machine using mu version 0.2, scanning 10000 messages takes around 92 seconds, or about 110 messages per second. Fortunately, a full scan has to be done only once, after that it suffices to index the changes, which goes much faster.
There is ongoing work on optimizing mu-index ; so hopefully future versions will be faster (note that version 0.2 is almost three times faster than version 0.1).
mu-index stores the information it finds in the mu-directory in two databases:
The first one is mu-sqlite.db-<version> , which is an SQLite3 database with meta data about the indexed messages. One can access this database with the sqlite3(1) command line tool. In the mu-source code, you can find the database schema in index/storage.sql.
The second one is mu-xapian.db-<version> , which is a Xapian database and contains content data about indexed messages found.
The database schema might change in future versions; however note that the <version> refers to the database version , which is not necessarily following the versions of mu itself.
NOTE: It is probably not a good idea to run multiple instances of mu-index that write to the same database at the same time. No data loss should occur, but one or more of the instance might experience errors due to database locks.
Also, before indexing has completed, searches for messages may fail, even if they have already been indexed, as some of the esssential database information will only be written at the end of the indexing.
--maildir=, -m <maildir> set the full path to the maildir; note that you can also specify this path as a non-option argument to mu-index ; if you use both, the non-option argument wins.
--quiet|-q makes mu-index not put out any progress info during its indexing. This is not the default, as running may take quite some time, and might confuse novice users.
--log-stderr, -s write logging information to standard error instead of to <mu-home-directory>/mu-find.log, which is the default.
--log-append, -a append to the log file instead of overwriting it for every run, which is the default.
--debug, -d add a lot of logging for debugging purposes
--tune-sqlite-transaction-size= --tune-xapian-transaction-size= <size> Sets the number of messages that are updated/inserted per transaction, for sqlite and Xapian. Setting the number higher improves the performance, but also increases the memory usage very significantly. And of course, in case of problems, up to changes will be rolled back (this is very rare though). For SQlite, the default is 100 and for Xapian it is 1000. It seems that setting the value higher does not improve performance very much.
--tune-synchronous= <sync> Determines whether we wait for changes to be written to disk before continuing; possible values for sync are 2 (full synchronization), 1 (normal), 0 (no synchronization), with the latter being the fastest. Default is 0 (no synchronization), as the mu databases are indexing the real data in maildirs, there is little risk for data loss.
This option corresponds to PRAGMA synchronous in http://www.sqlite.org/pragma.html Values other that 0,1,2 for sync are ignored.
--tune-temp-store= <store> Determines where we store temporary data is stored; options are 0 (default), 1 (file) or 2 (memory). The latter is much faster, but consumes more memory. The default value is 2.
This option corresponds to PRAGMA temp_store in http://www.sqlite.org/pragma.html Values other that 0,1,2 for store are ignored.
--tune-sort-inodes determines whether we sort the inodes before scanning a directory. When using an ext3 filesystem with the dir_index option enabled, this gives significant speedups. It does not seem to affect other filesystems very much. The parameter takes the values 0 (turn off) or 1 (turn on). It is on by default.
Again, we stress that in most cases, there should be no reason to use touch these tuning options. However, if you are in a resource-constrained environment, you could opt for using less memory, at a considerable speed penalty.
[mu] debug=false [mu-index] maildir=~/MyMaildir
Note that command line arguments take precedence over the configuration file.
mu-index ignores messages it cannot read or stat(2) ; but failure to read or stat will be logged. Files starting with '.' are ignored, but directories are not. Thus, if there is a message .dotdir/new/mymsg1234 it will be indexed. This allows indexing Maildir++ directories, as used by CourierIMAP and Dovecot
mu-index processes messages in cur/ and new/ leaf directories; it will ignore messages in tmp/
Thus, [....]/tmp/msg02 will be ignored, while [....]/new/msg01 won't.
On the other hand, [....]/tmp/cur/msg03 would not be ignored, while [....]/cur/tmp/msg04 would.
Note: single messages that are added by providing their full pathname to mu-index will not have their path checked.