Date: Mon, 12 Apr 2010 16:41:21 +0200 (CEST)
From: racin@free.fr
To: Jameson Rollins <jrollins@finestructure.net>
Message-ID:
 <457171623.7414151271083281537.JavaMail.root@zimbra1-e1.priv.proxad.net>
In-Reply-To: <87tyrgeopc.fsf@servo.finestructure.net>
Subject: Re: please eat my data!
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Notmuch list <notmuch@notmuchmail.org>
Precedence: list


----- "Jameson Rollins" <jrollins@finestructure.net> a =C3=A9crit :

> On Mon, 12 Apr 2010 15:33:35 +0200, "Sebastian Spaeth"
> <Sebastian@SSpaeth.de> wrote:
> > fsync is really killing xapian (and notmuch). What suffers, are the
> > boolean prefixes (tag, id, and thread). Using libeatmydata (which
> > disables fsync) shows a 10x speedup for tagging. The speedup is
> only
> > factor 2 for e.g. from: searches. This is ext4 on recent stock
> > Ubuntu. Given that search by tag and thread are performed really
> often
> > (each time I advance a thread, for example), that really hurts.
>=20
> Wow, this is really interesting, Sebastian.  For those of us not in
> the
> know, can you explain what libeatmydata is and how it's used?  It
> sounds
> like something I would *not* want to use!  So you didn't have to
> recompile here, and only had to set LD_PRELOAD=3D./libeatmydata.so?  Is
> there any drawback to what you're doing here?
>=20
> jamie.
>=20

It seems like it is a small library that implements fsync as no-op. Using L=
D_PRELOAD=20
allows to overloads the libc's fsync definition by libeatmydata's one. Maki=
ng writes faster,
but no longer crash-safe.

Matthieu