Notmuch success: Xapian database corrupt

[Ben Gamari]

On Wed, 21 Apr 2010 17:17:16 -0700, Carl Worth <cworth at cworth.org> wrote:
>
> I'm not aware of any bugs in notmuch that can result in a corrupt Xapian
> database. In fact, this can't be a bug in notmuch alone (since Xapian is
> detecting the corruption). There must at least be a bug in Xapian or
> else some lower-level failure is occurring (disk full?) that Xapian
> can't deal with.
> 
> I've not yet encountered a corrupt Xapian database, so I'm afraid I
> don't have any tips to help you with that.
> 
Nor have I experienced any corruption issues. I'd say just hope that it
was an isolated incident.

> But I'm also surprised to hear that it takes you days to incorporate
> your mail into a notmuch database. I have over 600 thousand messages
> myself, and it takes a few hours (maybe 4?) to incorporate all of these
> messages, but not days, (also with an Intel SSD).
> 
6e5 messages / 4 hours = ~40 messages/s. I don't believe I have ever
seen more than 0 messages per second average on my box (granted, with a
spinning disk, but I'm generally getting 0.05 messages/second or so), so
you are not the only one experiencing such abysmal performance. I sent a
message[1] to the list about this a few weeks ago, and Olly and others
had some productive input, but nothing that seemed too promising as far
as fixing the issue. I then took the issue to the LKML[2], although this
hasn't resulted in much progress. I recently switched from ext4 to btrfs
and both are quite poor when it comes to notmuch performance, so I'm
honestly not entirely convinced the problem can be placed exclusively on
the file system.

I know that the disk is capable of 20MByte/second sustained (peak of
60MByte/second), however I'm lucky to see a throughput of several
hundred kByte/second under the workload presented by notmuch.  I have
plenty of perf/blktrace data of notmuch new sessions if anyone is
interested, but there were unfortunately no takers on the lkml.

I am under the impression that Xapian is doing some really
knuckle-headed things when it comes to fsync()ing and the like, but I
really have a difficult time believing that is the sole issue while
others are getting perfectly acceptable performance with spinning disks.

I would love to get this issue solved, but my experience is definitely
quite limited in the file system/block I/O department and the semester
is definitely severely limiting the amount of time I am able to invest
in the problem, so I find myself pretty much at the mercy of whoever has
time to parse the data. If you are that person, I would be elated to
provide you with whatever data you might want/need

- Ben


[1] id:20100315090401.GA29891 at glaive.weftsoar.net
[2] id:4b9fa440.12135e0a.7fc8.ffffe745 at mx.google.com