From fa08f0474b1b5bfe3a77de341dbc54a34cbd8b50 Mon Sep 17 00:00:00 2001 From: Vladimir Marek Date: Tue, 14 Aug 2012 18:04:42 +0200 Subject: [PATCH] Re: Alternative (raw) message store (i.e. instead of maildir) --- d4/35fc61ec6f3260e4a45e48238c6341a5fbf4ac | 97 +++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 d4/35fc61ec6f3260e4a45e48238c6341a5fbf4ac diff --git a/d4/35fc61ec6f3260e4a45e48238c6341a5fbf4ac b/d4/35fc61ec6f3260e4a45e48238c6341a5fbf4ac new file mode 100644 index 000000000..b5ff6b1fe --- /dev/null +++ b/d4/35fc61ec6f3260e4a45e48238c6341a5fbf4ac @@ -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 CA1BA431FC2 + for ; Tue, 14 Aug 2012 09:06:09 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -4.999 +X-Spam-Level: +X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_HI=-5, UNPARSEABLE_RELAY=0.001] + 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 5ksYn0KIjBYG for ; + Tue, 14 Aug 2012 09:06:09 -0700 (PDT) +Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 67C2D431FAE + for ; Tue, 14 Aug 2012 09:06:09 -0700 (PDT) +Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) + by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with + ESMTP id q7EG65ZE002765 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); + Tue, 14 Aug 2012 16:06:06 GMT +Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) + by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id + q7EG64RP014072 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); + Tue, 14 Aug 2012 16:06:04 GMT +Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) + by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id + q7EG62SG000440; Tue, 14 Aug 2012 11:06:02 -0500 +Received: from pub.cz.oracle.com (/10.163.20.32) + by default (Oracle Beehive Gateway v4.0) + with ESMTP ; Tue, 14 Aug 2012 09:06:02 -0700 +Date: Tue, 14 Aug 2012 18:04:42 +0200 +From: Vladimir Marek +To: Stewart Smith +Subject: Re: Alternative (raw) message store (i.e. instead of maildir) +Message-ID: <20120814160442.GO28321@pub.cz.oracle.com> +Mail-Followup-To: Stewart Smith , + Ciprian Dorin Craciun , + notmuch@notmuchmail.org +References: + + <20120811094635.GY28321@pub.cz.oracle.com> <874no613ms.fsf@flamingspork.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +In-Reply-To: <874no613ms.fsf@flamingspork.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Source-IP: acsinet21.oracle.com [141.146.126.237] +Cc: notmuch@notmuchmail.org +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: Tue, 14 Aug 2012 16:06:10 -0000 + +> > - fuse zip stores all changes in memory until unmounted +> > - fuse zip (and libzip for that matter) creates new temporary file when +> > updating archive, which takes considerable time when the archive is +> > very big. +> +> This isn't much of a hastle if you have maildir per time period and +> archive off. Maybe if you sync flags it may be... + +That might be interesting solution, maildir per time period. But still +fuse zip caches all the data until unmounted. So even with just reading +it keeps growing (I hope I'm not accusing fuse zip here, but this is my +understanding form the code). This could be simply alleviated by having +it periodically unmounted and mounted again (perhaps from cron). + +> > Of course this solution would have some disadvantages too, but for me +> > the advantages would win. At the moment I'm not sure if I want to +> > continue working on that. Maybe if there would be more interested guys +> +> I'm *really* tempted to investigate making this work for archived +> mail. Of course, the list of mounted file systems could get insane +> depending on granularity I guess... + +Well, if your granularity will be one archive per year of mail, it +should not be that bad ... + +-- + Vlad -- 2.26.2