On Fri, 03 Dec 2004, Igor Brezac wrote:
On Thu, 2 Dec 2004, Henrique de Moraes Holschuh wrote:
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
On Thu, Dec 02, 2004 at 09:20:20PM -0200, Henrique de Moraes Holschuh wrote:
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
On Thu, Dec 02, 2004 at 09:20:20PM -0200, Henrique de Moraes Holschuh wrote:
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
On Fri, 03 Dec 2004, Andreas Hasenack wrote:
On Thu, Dec 02, 2004 at 09:20:20PM -0200, Henrique de Moraes Holschuh wrote:
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
On Fri, 03 Dec 2004, Andreas Hasenack wrote:
On Thu, Dec 02, 2004 at 09:20:20PM -0200, Henrique de Moraes Holschuh wrote:
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
Zitat von Henrique de Moraes Holschuh [EMAIL PROTECTED]:
I believe the openldap rationale is that it is impossible to have good BDB
defaults. This affects Cyrus as well, I think.
However, for Cyrus, it is probably easy enough to come up with a bare
minimum setup for a 1000 concurrent
I didn't know reiser 3 would fully journal data (or that it has good
enough
write barriers and write optimization to make sure the filesystem never
returns before a fsync really means everything including data is on disk).
Is that correct? If it is, then reiser might be a better choice than
On Thu, 02 Dec 2004, Rob Mueller wrote:
We use reiserfs for our large cyrus installation. We changed from ext3
[...]
That was very interesting and useful data, thanks for posting it!
Ordered = Data is written before meta-data journal is committed. This
avoids filesystem and data corruption.
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,
Ordered would be best for a Cyrus spoll, and I guess Data would be best on
MTAs (when they have a small enough queue lifetime for most messages, and
the journal is large enough).
I think probably just test and find which one gives you the better
performance. We tended to find that data=journal
FYI anyone looking for NVRAM solutions for journals/meta-data storage, I
just found this page:
http://www.storagesearch.com/ssd-buyers-guide.html
Which looks to have lots of juicy info. If anyone knows anything about any
of these products or has feedback, I'd love to hear about it, and I'm sure
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
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
13 matches
Mail list logo
