From baa59d18393e8907fa994322e5c33dad49979383 Mon Sep 17 00:00:00 2001 From: David Mazieres Date: Mon, 14 Apr 2014 08:23:38 +1700 Subject: [PATCH] Re: Synchronization success stories? --- a5/e7bc70acb452ab4200515e34c9d16d75a28075 | 97 +++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 a5/e7bc70acb452ab4200515e34c9d16d75a28075 diff --git a/a5/e7bc70acb452ab4200515e34c9d16d75a28075 b/a5/e7bc70acb452ab4200515e34c9d16d75a28075 new file mode 100644 index 000000000..900bdb4a8 --- /dev/null +++ b/a5/e7bc70acb452ab4200515e34c9d16d75a28075 @@ -0,0 +1,97 @@ +Return-Path: + +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 4B094431FBD + for ; Sun, 13 Apr 2014 08:23:46 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id ZwdBmnbyIqoq for ; + Sun, 13 Apr 2014 08:23:42 -0700 (PDT) +Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 9E0C4431FBC + for ; Sun, 13 Apr 2014 08:23:42 -0700 (PDT) +Received: from market.scs.stanford.edu (localhost.scs.stanford.edu + [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id + s3DFNd5m017263; Sun, 13 Apr 2014 08:23:39 -0700 (PDT) +Received: (from dm@localhost) + by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3DFNc9s000555; + Sun, 13 Apr 2014 08:23:38 -0700 (PDT) +X-Authentication-Warning: market.scs.stanford.edu: dm set sender to + return-2deyg6wba3x6j2jhvku4s4gc2i@ta.scs.stanford.edu using -f +From: David Mazieres +To: Tilmann Singer , Brian Sniffen , + notmuch@notmuchmail.org +Subject: Re: Synchronization success stories? +In-Reply-To: <87ppklwin6.fsf@tils.net> +References: + <87ppklwin6.fsf@tils.net> +Date: Sun, 13 Apr 2014 08:23:38 -0700 +Message-ID: <87siphl0cl.fsf@ta.scs.stanford.edu> +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +Reply-To: David Mazieres expires 2014-07-12 PDT + +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 13 Apr 2014 15:23:46 -0000 + +Tilmann Singer writes: + +> The steps performed on a sync run are roughly like this: +> +> - local: notmuch new +> - local: notmuch search --output=messages .. +> - remote: notmuch new +> - remote: notmuch search --output=messages .. +> - 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. + +David -- 2.26.2