Tilmann Singer <t...@tils.net> writes:

> The steps performed on a sync run are roughly like this:
> - local: notmuch new
> - local: notmuch search --output=messages <some time ago>..<now>
> - remote: notmuch new
> - remote: notmuch search --output=messages <some time ago>..<now>
> - compare search results
> - run rsync for mails that only exist locally
>   (using notmuch search --output=files to get the filenames)
> - run rsync for mails that only exist remotely
>   (using notmuch search --output=files to get the filenames)

What happens if you get a message that's been stuck in a queue for a few
days and has an old Date: header?  Or if you get new messages that have
the same Message-ID as old ones?

> Synchronization of the notmuch tags database is only necessary when I
> switch between different client computers, which happens less
> frequently.

Do you use a laptop everywhere?  I've found that for switching between
my desktop machine at home, my laptop on the train, and my desktop at
work (which amounts to five switches a day), the notmuch dump time is
painfully slow--like well over 10 seconds for 100,000 messages.  Hook
that into notmuch-poll and you have a recipe for hanging emacs every
time you type "G".

Of course, I'm also experiencing the problem of "notmuch new" itself
being painfully slow, but at least that's now my bottleneck in switching
machines.  I suspect the source of the notmuch new problem is that I
have some huge, huge mailboxes.  Some of my maildir/cur directories are
multiple megabytes on a BSD FFS file system (no hashing, so linear
filename lookups in something that doesn't fit in the dcache).  On linux
ext4 things are much faster.  I intend to reorganize my maildir so that
there is a top-level directory with the year and hence no single
directory ever contains mail from more than one year.

notmuch mailing list

Reply via email to