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

[Igor Brezac]

On Thu, 2 Dec 2004, Henrique de Moraes Holschuh wrote:

> 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),

This Cyrus bug has been fixed a long time ago.  I've run cyrus with BDB 
4.1 or higher for almost two years without any issues.

> but also because
> of all the reports of problems with OpenLDAP.

Well, this is certainly a debatable issue.  The latest stable version of 
OpenLDAP will run only with BDB 4.2.52 or higher.  (BDB 4.3.21 is the 
latest and not without problems)  Sure there are folks with horror 
stories, but there are numerous folks who run OpenLDAP with great success 
in very busy environments.

> 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.

A correctly configured BDB 4.x environment will behave and perform well. 
I am yet to corrupt a BDB database to a point where the data is not 
recoverable.

For those interested, you can find BDB docs at 
http://www.sleepycat.com/docs/ref/toc.html.  As Henrique pointed out, BDB 
is very complex, but it can also do a very good job.

-- 
Igor
---
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