Andrew Morgan wrote:
> On Fri, 28 Jul 2006, Rich Graves wrote:
>
>> My question: So is *anyone* here happy with Cyrus on ext3? We're a
>> small site, only 3200 users, 246GB mail. I'd really rather not try
>> anything more exotic for supportability reasons, but I'm getting
>> worried that our plann
-- Rich Graves <[EMAIL PROTECTED]> is rumored to have mumbled on 28.
Juli 2006 15:52:17 -0500 regarding Re: High availability email server...:
My question: So is *anyone* here happy with Cyrus on ext3?
Yes. We use it on a SAN with a 800 GB partition for /var/spool/imap.
--
Sebastian Hagedorn
On Fri, 28 Jul 2006, Rich Graves wrote:
My question: So is *anyone* here happy with Cyrus on ext3? We're a small
site, only 3200 users, 246GB mail. I'd really rather not try anything more
exotic for supportability reasons, but I'm getting worried that our planned
move from Solaris 9/VxFS to RH
Fabio Corazza wrote:
Rich Graves wrote:
Clustered filesystems don't make any sense for Cyrus, since the
application itself doesn't allow simultaneous read/write. Just use a
normal journaling filesystem and fail over by mounting the FS on the
backup server. Consider replication such as DRDB or pr
"David S. Madole" <[EMAIL PROTECTED]> wrote:
That's just not true as a general statement. SAN is a broad term that
applies to much more than just farming out block devices. Some of the
more sophisticated SANs are filesystem-based, not block-based. This
allows them to implement more advanced func
Rich Graves wrote:
> Clustered filesystems don't make any sense for Cyrus, since the
> application itself doesn't allow simultaneous read/write. Just use a
> normal journaling filesystem and fail over by mounting the FS on the
> backup server. Consider replication such as DRDB or proprietary SAN
>
Clustered filesystems don't make any sense for Cyrus, since the
application itself doesn't allow simultaneous read/write. Just use a
normal journaling filesystem and fail over by mounting the FS on the
backup server. Consider replication such as DRDB or proprietary SAN
replication if you feel y
On Jul 28, 2006, at 1:40 PM, Pascal Gienger wrote:
So if Apple says that Xsan does not handle many files they admit
that their HFS+ file system is crap for many small files.
This is completely untrue. Xsan, although branded by Apple, is not
completely an Apple product. ADIC makes StorNext
> Sorry, please bear with my ignorance, I'm not very informed about NFS,
> but what's wrong with locking against a real block device?
NFS is a file sharing protocol that doesn't provide full locking
semantics the way block devices do.
> There are file systems like GFS that have been written for t
Pascal Gienger wrote:
> There are techniques to handle these situations - for xfs (as an
> example) consider having *MUCH* RAM in your machine and always mount it
> with logbufs=8.
Is XFS so RAM intensive?
> I would NEVER suggest to mount the cyrus mail spool via NFS, locking is
> important and f
> From: Pascal Gienger
>
> STOP!
> The capability to handle small files efficiently is related to the
> filesystem carrying the files and NOT to the physical and logical
> storage media (block device) under it.
>
> A SAN is a network where physical and logical block devices are shared
> between
> The capability to handle small files efficiently is related to the
> filesystem carrying the files and NOT to the physical and logical storage
> media (block device) under it.
Not necessarily true. All sorts of factors about the SAN, such as block
size, stripe size, RAID level(s), number of s
David Korpiewski <[EMAIL PROTECTED]> wrote:
I spent about 6 months fighting with Apple XSAN and Apple OSX mail to try
to create a redundant cyrus mail cluster. First of all, don't try it, it
is a waste of time. Apple states that mail on an XSAN is not supported.
The reason is that it simply wo
Hi,
you can also use DRBD for replication on the block level. Then you need no SAN
and have a shared nothing architecture. You will need a high speed link between
the sites (GBIT). An alternative is a SAN with replication. You can also use md
for this purpose (host based SAN raid). Two cheap M
Chris St. Pierre wrote:
We've put /var/lib/imap and /var/spool/imap on a SAN and have two
machines -- one active, and one hot backup. If the active server
fails, the other mounts the storage and takes over. This is not yet
Also consider /var/spool/{mqueue,clientmqueue,postfix}.
Depending on
David Korpiewski wrote:
I spent about 6 months fighting with Apple XSAN and Apple OSX mail to
try to create a redundant cyrus mail cluster. First of all, don't try
it, it is a waste of time. Apple states that mail on an XSAN is not
supported. The reason is that it simply won't run. The Xsa
On 28 Jul 2006, at 05:48, Pascal Gienger wrote:
David Carter <[EMAIL PROTECTED]> wrote:
Do the mailboxes have the same UniqueID (see cyrus.header files)? The
replication engine expects UniqueID to be unique. Cyrus makes a
bit of a
hash of renaming user inboxes (user.XXX -> user.XXX.Uni). Remov
I spent about 6 months fighting with Apple XSAN and Apple OSX mail to
try to create a redundant cyrus mail cluster. First of all, don't try
it, it is a waste of time. Apple states that mail on an XSAN is not
supported. The reason is that it simply won't run. The Xsan can't
handle the large
Problem solved, DUH!Courtesy of Pterobyte (Alex) on the Apple Mailserver forum, quota report is generated by the OSX Server Admin tool, when it is open at the Maintenance tab - it refreshes every minute and generates a quota report each time. Aaarrghh ;-)-davidOn 28 Jul 2006, at 12:36, David Brown
Chad--
We've put /var/lib/imap and /var/spool/imap on a SAN and have two
machines -- one active, and one hot backup. If the active server
fails, the other mounts the storage and takes over. This is not yet
in production, but it's a pretty simple setup and can be done without
running any bleeding
On 2006-07-28 at 11:05 +0100, Andrew Findlay wrote:
> Headers are not usually very large, so I would be more inclined to
> the idea that the index should store every header (perhaps with a
> blocklist to avoid things like Received:)
Those fine folk at Cambridge who introduced replication have a nu
Apple OSX Server 10.4.7I occasionally get the following system.log message repeated every minute...Jul 27 08:52:20 servername sudo: root : TTY=unknown ; PWD=7 ; USER=cyrusimap ; COMMAND=/usr/bin/cyrus/bin/cyrus-quota -rThis repeats every minute for sometimes hours and eventually stops after this sy
Ooops, found the correct term I was looking for. "Single instance store" is
what I was intending to ask about.
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
On Fri, Jul 28, 2006 at 10:37:43AM +0100, Alain Williams wrote:
> Might it not be better to have Cyrus 'learn' what header lines are needed,
> rather than just bloating the list with more headers. The set of headers
> would needed to be dynamically changable. The points are:
>
> 1) different IMA
I really don't have a strong enough grasp of Cyrus terminology at this
point. Sorry about that, perhaps duplicate suppression is not the right
term. What I meant was you send a message to 30 inboxes at once, as I
understood it Cyrus only stores one copy and references the other 29. At
least with
David Carter <[EMAIL PROTECTED]> wrote:
Do the mailboxes have the same UniqueID (see cyrus.header files)? The
replication engine expects UniqueID to be unique. Cyrus makes a bit of a
hash of renaming user inboxes (user.XXX -> user.XXX.Uni). Removing the
cyrus.header file and running reconstruct
On Fri, 28 Jul 2006, Pascal Gienger wrote:
sync_client seems to try to RENAME the Inbox to the subfolder "Uni"
which is complete nonsense.
Do the mailboxes have the same UniqueID (see cyrus.header files)? The
replication engine expects UniqueID to be unique. Cyrus makes a bit of a
hash of re
On Fri, Jul 28, 2006 at 10:41:19AM +0200, Daniel Eckl wrote:
>
>
> Andrew Findlay schrieb:
> >On Fri, Jul 28, 2006 at 12:18:12AM -0700, Nikola Milutinovic wrote:
> >
> >>So, perhaps we could state that the desired behavior of any IMAP
> >>client would be to fetch only those message headers it ned
We had a strange exception here, a user's inbox could be replicated without
problems, but doing it for a second time does not do it.
sync_client was invoked like this:
sync_client -v -u X
Jul 28 10:52:17 priscilla sync_client[21326]: RENAME received NO response:
Rename failed user.XXX
Andrew Findlay schrieb:
On Fri, Jul 28, 2006 at 12:18:12AM -0700, Nikola Milutinovic wrote:
So, perhaps we could state that the desired behavior of any IMAP
client would be to fetch only those message headers it nedds to and
perhaps a bit more. In case of TB, that would transalte to fetching
On Fri, Jul 28, 2006 at 12:18:12AM -0700, Nikola Milutinovic wrote:
> So, perhaps we could state that the desired behavior of any IMAP client would
> be to fetch only those message headers it nedds to and perhaps a bit more. In
> case of TB, that would transalte to fetching only headers that wou
Well, I'm guessing here, because I never tried a murder setup.
But as I understand: This feature suppresses duplicate mails to the
_same mailbox_. So I do not see the sense in a duplicate database which
spans over multiple backends. Du you want that if user A on one backend
gets an email and t
Thank you all for your responses. This was insightful.
So, perhaps we could state that the desired behavior of any IMAP client would
be to fetch only those message headers it nedds to and perhaps a bit more. In
case of TB, that would transalte to fetching only headers that would be visible
to t
33 matches
Mail list logo
