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 c
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 see
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. Thi
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
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 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
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
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 sa
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
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 ac
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-i
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 corruptio
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 ext3
13 matches
Mail list logo
