, 2002 7:33 PM
To: Amos Gouaux
Cc: [EMAIL PROTECTED]
Subject: Re: multiple cyruses via SAN
Amos Gouaux wrote:
...
Though, I will say
this: we recently switched to skiplist for mailboxes.db and at least
so far, it beats the pants off of Berkeley DB.
Ditto. We switched to skiplist last week (from
On Thu, 21 Mar 2002 08:32:37 -0800,
David Mendenhall [EMAIL PROTECTED] (dm) writes:
dm I know I've seen snippets about this run across this list, but does anybody
dm have a step-by-step for switching from Berkeley DB to skiplist in cyrus
dm 2.0.16 ?
For 2.0.16? I don't think you can. You
]
|
| Subject: Re: multiple cyruses via SAN
|
--|
On Tue, 19 Mar 2002, Ken Murchison wrote:
Chris
The Cyrus code already handles the locking between multiple processes,
so an imapd running on a different box is a subtle (if any)
difference,
provided that the shared filesystem handles read/write access from
multiple hosts and provides UNIX file locking semantics.
The only filesystem
[EMAIL PROTECTED] schrieb am Wed, Mar 20, 2002 at 10:11:26AM +0200:
So guys, what do you suggest in theorethical level?
What would have to be done for multiple cyruses to work? Put a SQL DB in
backend?
I just won't do it. The technology at hand is definitely not in shape for
this if you
On Wed, 20 Mar 2002 10:40:20 +0100,
Birger Toedtmann [EMAIL PROTECTED] (bt) writes:
bt If you want a production system that scales and is high available/has failover
bt capablilities, set up several boxes with _separate_ userspace and multiplex
bt all connections to and from it according to
Amos Gouaux wrote:
...
Though, I will say
this: we recently switched to skiplist for mailboxes.db and at least
so far, it beats the pants off of Berkeley DB.
Ditto. We switched to skiplist last week (from BDB3), and the
performance improvement is amazing! Plus of course, no more deadlocks...
Some random rambling on this topic. I'm not sure I'm contributing a whole
lot new.
In general, distributed filesystems are nice mechanisms for doing general
purpose stuff. However, when you try to layer very specific tasks on top
of distributed filesystem, you may run into problems where
Jeremy Howard schrieb:
Amos Gouaux wrote:
...
Though, I will say
this: we recently switched to skiplist for mailboxes.db and at least
so far, it beats the pants off of Berkeley DB.
Ditto. We switched to skiplist last week (from BDB3), and the
performance improvement is amazing!
On Thu, 21 Mar 2002 07:40:30 +0100,
Simon Matter [EMAIL PROTECTED] (sm) writes:
sm OT, but did you upgrade all dbs from DB3 to skiplist? Is it possible at
sm all? I'm not sure about this but as I understand the configure script it
sm should be possible now to use skiplist for every db. So my
--On Tuesday, March 19, 2002 6:29 PM +0200 [EMAIL PROTECTED]
wrote:
Here is the idea:
CyrusBox1 CyrusBox2
\ /
`-\__/
SAN
The questions are:
1) Can it be done with out
]
|
| cc:
|
| Subject: Re: multiple cyruses via SAN
[EMAIL PROTECTED] wrote:
Here is the idea:
CyrusBox1 CyrusBox2
\ /
`-\__/
SAN
The questions are:
1) Can it be done with out modifications to cyrus code?
2) if not, what
On Tue, 19 Mar 2002 [EMAIL PROTECTED] wrote:
Idea is that they share same mails/rules and acti simultaneously. A
loadbalancer will stand in front of those boxes.
Its certainly something I wanted to try for a long time now. There has
been many requests for this on the list, but I'm not aware
Hello,
We would like to use a shared filesystem. Will ALL the accounts on
each server. Then we would use a load balancing package ( Resonate )
in front of the servers. Should one server fail the service would
continue.
Network
/\
So you think if i simply had cxfs, it would work w/o problems?
Earl R Shannon wrote:
Hello,
We would like to use a shared filesystem. Will ALL the accounts on
each server. Then we would use a load balancing package ( Resonate )
in front of the servers. Should one server fail the service would
continue.
Network
[EMAIL PROTECTED] wrote:
So you think if i simply had cxfs, it would work w/o problems?
I _think_ so. I've never tried it an make no guarantees. Keep in mind
that CXFS is only available on IRIX and Solaris (and may require IRIX
servers). SGI is supposedly working on Linux, Win32 and
Hello,
Actually, there is no SAN server. The SAN is to be implemented
with fiber channel devices. The imap servers will have a fiber
channel interface which is connected to a fiber channel switch.
Also connected to the fiber channel switches are the RAID units
with the actual storage.
As for
On Tue, 19 Mar 2002, Ken Murchison wrote:
The Cyrus code already handles the locking between multiple processes,
so an imapd running on a different box is a subtle (if any) difference,
provided that the shared filesystem handles read/write access from
multiple hosts and provides UNIX file
:
|
| Subject: Re: multiple cyruses via SAN
|
--|
Actually, it MAY just work, but I kind of doubt
]
|
| cc:
|
| Subject: Re: multiple cyruses via SAN
No, it will not work. A shared file system with unix lock semantics is
not enough, Berkeley DB will not work in this environment because it
uses shared memory. The system is single host bound.
Cheers
Chris
[EMAIL PROTECTED] wrote:
So you think if i simply had cxfs, it would work w/o
Hmm,
I think there's a way to persuade berkeleydb to work without shm. Not sure
tho
-alex
On Tue, 19 Mar 2002, Chris Audley wrote:
No, it will not work. A shared file system with unix lock semantics is
not enough, Berkeley DB will not work in this environment because it
uses shared
Chris Audley wrote:
No, it will not work. A shared file system with unix lock semantics is
not enough, Berkeley DB will not work in this environment because it
uses shared memory. The system is single host bound.
Yup. Good call. This could be worked around or just use non-BDB
cyrusdb
On Tue, 19 Mar 2002, Ken Murchison wrote:
Chris Audley wrote:
No, it will not work. A shared file system with unix lock semantics is
not enough, Berkeley DB will not work in this environment because it
uses shared memory. The system is single host bound.
Yup. Good call. This
26 matches
Mail list logo
