Cyrus crashed on redundant platform - need better availability?

Paul Dekkers Paul.Dekkers at surfnet.nl
Sat Sep 11 08:36:55 EDT 2004


Hi,

Michael Loftis wrote:

> The theory only translates if you're using a JOURNALED file system.=20
> Linux ext3, reiserfs.... AIX JFS, Sun/others veritas are all examples=20
> of this. AFAIK FreeBSD hasn't any journalling file systems,=20

Hmm, some say the use of softupdates preclude a journaling filesystem=20
(see for instance http://kerneltrap.org/node.php?id=3D6). It's all a bit=20
different with FreeBSD :-)

> That said, the machine shouldn't' have crashed in the first place, but=20
> you are running 5.x which is clearly labeled as *NOT* production (4.10=20
> for that)... All of my produciton boxen are 4.x based (of the FreeBSD=20
> herd)

You are right - 5.x is not stable yet, but 5.3 is very close to it.=20
Since 5.3 is coming we thought it would be easier to install with 5.2.1=20
and upgrade to 5.3 rather then use 4.10 and upgrade that... And we might=20
indeed face a 5.2.1-bug, that's why I mentioned the "SMP", "3G" and=20
"GEOM" things, but might as well be something else with 5.x.
Something else that was a vote for 5.x was the filesystem; 4.10 does not=20
have UFS2.

Apart from solving the issues we have with the machine I think we'd=20
really look at the options for having redundany in application, as=20
sketched in the "High availability ... again" subject :-) Maybe we'd=20
install 5.3-BETA on the platform (I'll discuss it with another FreeBSD=20
expert here :-))

Jure Pe=C4=8Dar wrote:

>> >The only high availability i see here is the google way. Cyrus is
>> >offering you that with the 'murder' component.
> =20
>
>> That's not really availability, but distributed risk.
> =20
>
>Exactly ... with murder taking care of keeping duplicated mailboxes in s=
ync
>over a pool of backend machines (as i mentioned in the other mail), this
>would be perfect for all of us, i guess.
> =20
>
Well, I don't know if it needs to be murder or some extension in the=20
storage or something, but that's roughly my idea indead; synchronising=20
two (or more? that's harder maybe) servers, just like doing an imapsync=20
or rsync, but then... well, better! :-) (And without losing states and=20
so forth.)

The SPOF of the SCSI controller in the RAID box I'm willing to accept,=20
but the filesystem is a bit harder.

I'm curious what cyrus developers think of this, and I'm interested in=20
what we can do to help.

Paul


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




More information about the Info-cyrus mailing list