From 13caec009f5f06cf1d957d025385134e2c4fc55e Mon Sep 17 00:00:00 2001 From: Tilmann Singer Date: Sun, 13 Apr 2014 21:08:49 +0200 Subject: [PATCH] Re: Synchronization success stories? --- 27/8b2df1dec1504ee32b5a389bd9ab9398ef170b | 127 ++++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 27/8b2df1dec1504ee32b5a389bd9ab9398ef170b diff --git a/27/8b2df1dec1504ee32b5a389bd9ab9398ef170b b/27/8b2df1dec1504ee32b5a389bd9ab9398ef170b new file mode 100644 index 000000000..8b2c0dbf3 --- /dev/null +++ b/27/8b2df1dec1504ee32b5a389bd9ab9398ef170b @@ -0,0 +1,127 @@ +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 23004431FBD + for ; Sun, 13 Apr 2014 12:09:01 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + 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 HGdk+e9BtznK for ; + Sun, 13 Apr 2014 12:08:53 -0700 (PDT) +Received: from goto.r-w-x.org (goto.r-w-x.org [176.9.70.178]) + by olra.theworths.org (Postfix) with ESMTP id 74E22431FBC + for ; Sun, 13 Apr 2014 12:08:53 -0700 (PDT) +Received: from localhost (55d456ec.access.ecotel.net [85.212.86.236]) + by goto.r-w-x.org (Postfix) with ESMTPSA id 195C9E5C; + Sun, 13 Apr 2014 21:08:50 +0200 (CEST) +Received: by localhost (sSMTP sendmail emulation); + Sun, 13 Apr 2014 21:08:49 +0200 +From: Tilmann Singer +To: David Mazieres expires 2014-07-12 PDT + , + Brian Sniffen , notmuch@notmuchmail.org +Subject: Re: Synchronization success stories? +In-Reply-To: <87siphl0cl.fsf@ta.scs.stanford.edu> +References: + <87ppklwin6.fsf@tils.net> <87siphl0cl.fsf@ta.scs.stanford.edu> +User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-unknown-linux-gnu) +Date: Sun, 13 Apr 2014 21:08:49 +0200 +Message-ID: <8738hhvygu.fsf@tils.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha1; protocol="application/pgp-signature" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +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 19:09:01 -0000 + +--=-=-= +Content-Type: text/plain +Content-Transfer-Encoding: quoted-printable + +David Mazieres writes: +> What happens if you get a message that's been stuck in a queue for a few +> days and has an old Date: header? + +It would be missed. I have set the timespan to look backwards for new +mail to one month to be a bit safer against the stuck-in-queue cases, +but mails with older Date: headers would definitely get missed. + +The current output of notmuch count "*" is the same on both the client +and the server, so it seems I didn't run into this problem yet (maybe I +was just lucky). + +> Or if you get new messages that have +> the same Message-ID as old ones? + +Is that even possible? I thought that notmuch guarantees the uniqueness +of indexed message ids. The only reference I could find without trying +to read the code was this thread id:87mwyz3s9d.fsf@star.eba from 2012, +which supports the assumption. + +>> 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". + +I have one laptop and one desktop and switch between them almost daily, +and run a hibernate script that does notmuch dump + git push, and a +resume script that does git pull + notmuch restore. For hibernate / +resume the speed of those operations is acceptable, but I wouldn't want +to incur that wait for every time checking for new mail. + +Here is how long they take (on a machine with an SSD, which certainly +helps): + +$ time notmuch dump --format=3Dbatch-tag | sort > /tmp/notmuch.dump +real 0m3.643s +user 0m3.593s +sys 0m0.140s +$ time notmuch restore < /tmp/notmuch.dump +real 0m3.719s +user 0m3.357s +sys 0m0.357s +$ notmuch count=20 +117118 + + + +Til + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2.0.22 (GNU/Linux) + +iQEcBAEBAgAGBQJTSuDBAAoJEIPWI/RHW7lzuHkH/1ToBjsD6Wri2mwf8LxJ2hqR +p4Lyq2U9w/ZP7YyBKjFwyhOAVJ8Cj9bbLw84kbUIJoxLRTzwJHPB4aEv67ktD+3y +4UCQUf5579BdnjASBblHDP3NySsJkSybkn1N2WCCGhoiAyvK+0J5CizebcAYVELv +FY8lG4c9aWaMi2KNiOeBxjKu8NrwKMVI1munBDIGhNxiAAqYqqyfszJQQcvrOkAK +g40CwuugOvXt20iMloBFsBxz+fv3jvHMdpyVT4+w7Rb3PoREkFt5tf5FL0xMmPIV +hrIlfVrqTCdL9lMql3ppOcNEbsQIZzq6oAhWIBLGW8RaPO6eUoMvDFJsPwOycfg= +=imbw +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2