ReiserFS and general cyrus filesystem usage information - was Re: best filesystem for imap server

[Henrique de Moraes Holschuh]

On Thu, 02 Dec 2004, Andreas Hasenack wrote:
> On Thu, Dec 02, 2004 at 06:48:02PM -0200, Henrique de Moraes Holschuh wrote:
> > > wouldn't be appropriate. We could have used bdb, but generally have had 
> > > lots of problems with bdb so don't entirely trust it...
> > 
> > I don't know of anyone sane that trusts any BDB on the 4.x series.
> 
> With cyrus-imapd, that may be so. But don't generalize, BDB is quite robust.

Well, 3.2.9 as packaged by Debian IS robust.  I don't have a single
misbehaviour (let alone one that caused data loss) reported against it, I
think.

Now, for 4.x I do not agree with you. As far as I am concerned, the 4.x
series is *not* to be trusted yet.  It is not just because of Cyrus (after
all, a bug in Cyrus code might cause BDB 4.x to misbehave), but also because
of all the reports of problems with OpenLDAP.

As a first example (and just like you said), if you don't get the DB_CONFIG
stuff exactly right, you can get anything from lock ups to environment
corruption.  This is quite easy to hit with OpenLDAP.  From what you wrote,
I guess subversion will also get hit by this one if DB_CONFIG is not
optimal for your dataset.

Second, it is prone to behave badly in non-trivial workloads on non-trivial
apps on non-trivial (i.e. not UP) boxes.  Which is exactly the kind of thing
you have on any big Cyrus or OpenLDAP deployment.  I have some hopes that
the very latest 4.2 fixes this.  I *do* know the others didn't, since I've
experienced the crashes myself.

BDB 4.x is a complex piece of software, and it shows.

> It's heavily used by openldap and subversion. We, for example, have a

And at least with openldap, it causes a lot of trouble.

> subversion repository with about 50Gb of data on a single berkeley
> database file (version 4.2.52 + 2patches):

Heavy concurrent load on non-UP machines seem to be a much more common cause
of trouble with BDB than database size.  Index size does couse trouble (when
DB_CONFIG is not correctly sized), though.

> default values for important settings, data corruption *will* happen.

Indeed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html