Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is Qmail some kind of joke?

22 views
Skip to first unread message

vl...@my-deja.com

unread,
Jun 6, 1999, 3:00:00 AM6/6/99
to

I'm a Linux newbie so perhaps I just don't have a clue.

Qmail's author either doesn't respond to email or doesn't read his
email.

The link to Qmail RPMS from the qmail.org hasn't worked for weeks. No
one I send mail to from the qmail site seems to respond.

Getting Qmail and WU IMAP and Maildir to work together is a highly
undocumented task.

The patches to IMAP from the Qmail site apparently don't support
Maildir.

The authors of those patches don't respond to email.

Does anyone have docs on getting Qmail and Cyrus working?


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

(Scott Schwartz) Scott Schwartz

unread,
Jun 6, 1999, 3:00:00 AM6/6/99
to
vl...@my-deja.com writes:
> Qmail's author either doesn't respond to email or doesn't read his
> email.

There's a very active qmail mailing list, and a web site for updates,
which the qmail documentation refers you to.

> The link to Qmail RPMS from the qmail.org hasn't worked for weeks. No
> one I send mail to from the qmail site seems to respond.

There's no need to use RPMs. Fetch and compile the source; it's just
as easy.

> Getting Qmail and WU IMAP and Maildir to work together is a highly
> undocumented task.

That's because the UW IMAP authors don't want you to use Maildir, for
reasons which are obscure.

> Does anyone have docs on getting Qmail and Cyrus working?

Check the mailing list archives.


Osma Ahvenlampi

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
vl...@my-deja.com writes:
> The link to Qmail RPMS from the qmail.org hasn't worked for weeks. No
> one I send mail to from the qmail site seems to respond.

Qmail's license is unfriendly to RPM's - it can not be distributed in
a modified archive. That means that making RPM's is painful (generally
you get the source and a SPEC file separately and build it yourself).

It's easier to just build Qmail from source, although I do the RPM bit
anyway because I prefer the system software to be in the RPM database
for the long run.

> Getting Qmail and WU IMAP and Maildir to work together is a highly
> undocumented task.

Because Maildir sucks performance-wise. A small patch in WU imapd will
allow it to fetch mail from $HOME/Mailbox, and sticking an empty
mbx-format file named INBOX in $HOME as well will guarantee fast imap
service for the inbox.

--
Is a computer language with goto's totally Wirth-less?
Osma Ahvenlampi <oa at iki fi> (damn spammers)

Mark Crispin

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
On 6 Jun 1999, Scott Schwartz wrote:
> That's because the UW IMAP authors don't want you to use Maildir, for
> reasons which are obscure.

Because Maildir has dreadful performance (worse than any supported mailbox
format) and doesn't scale, that's why. There are other technical (and
non-technical) reasons as well; but performance so wretched that you
wouldn't want to use it for a mailbox with more than a handful of messages
is enough.

Third-party Maildir drivers are available; however if you use them it is
strictly at your own risk (don't even think about sending in bug reports
or complaining about it being slow).

I doubt that you'll find the Cyrus guys any more willing to consider
supporting Maildir. They're probably even less willing than we are,
especially since it would make Cyrus slower than our server.

The recommended mailbox format in the UW IMAP toolkit is mbx, which is
much faster than the standard UNIX mailbox format and allows shared
read/write access.

In the future, we are looking into databases for very high performance
mailbox formats. Cyrus is halfway to being a database; it is not strictly
a one-file/one-message format since it uses an auxillary index that (among
other things) contains preparsed ENVELOPEs and BODYSTRUCTUREs. That's
where Cyrus gets a lot of its performance benefit.

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message. *
Science does not emerge from voting, party politics, or public debate.


D. J. Bernstein

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
A few months ago, a user asked me why Pine was providing such poor NFS
performance for writes to a standard mbox.

I measured what was actually going on. The problem, in short, was Pine's
failure to buffer writes properly. One version was even using writev();
to experts, writev() screams ``THIS PROGRAM NEEDS BUFFERING!''

The user tried Mutt, http://www.mutt.org, and immediately noticed the
dramatic improvement in mbox performance.

So I find it richly amusing to see Crispin talking about mailbox speed
as a reason to avoid supporting a popular, NFS-safe, crashproof format
for incoming mail.

---Dan

P.S. Mutt also supports maildir, so users can try it out to see how
maildir actually performs in practice.

(Scott Schwartz) Scott Schwartz

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
Mark Crispin <m...@CAC.Washington.EDU> writes:
> > That's because the UW IMAP authors don't want you to use Maildir, for
> > reasons which are obscure.
>
> Because Maildir has dreadful performance (worse than any supported mailbox
> format) and doesn't scale, that's why.

The phrase "doesn't scale" is usually a codeword for "works fine in
the usual case". In the limit nothing scales, and, moreover, not
every technique has to be used in every situation (that's why you
support a number of different mailbox formats, right?) Since I'm
experiencing the usual case, and not an extreme one, maildir works
nicely. That's just an empirical fact, not a value judgement.

> There are other technical (and
> non-technical) reasons as well; but performance so wretched that you
> wouldn't want to use it for a mailbox with more than a handful of messages
> is enough.

But see, unless you say what those things are, they remain obscure. :-)

And, not to belabor the obvious, but lots of people *do* use Maildir
and enjoy acceptable performance. That issue's been decided; now it's
just a question of which (if any) imap server to run.

> Third-party Maildir drivers are available; however if you use them it is
> strictly at your own risk (don't even think about sending in bug reports
> or complaining about it being slow).

Ironically, pretty much the only complaint that people have about
maildir is that you won't support it!


Mark Crispin

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
On 7 Jun 1999, D. J. Bernstein wrote:
> I measured what was actually going on. The problem, in short, was Pine's
> failure to buffer writes properly. One version was even using writev();
> to experts, writev() screams ``THIS PROGRAM NEEDS BUFFERING!''

I refuse to get into a pissing contest with this individual. It is a
monumental waste of time.

Here are the facts:

Two issues relate to unix-format mailbox performance; newline conversion
and checkpointing (that is, updating the file on disk). For most users,
newline conversion is in the noise; checkpointing is what generates most
of the complaints. Since that's the only "disk writes" that are done,
the comment above must refer to checkpointing.

There is not a single writev() call in the code, and there has not been
for several years. The old writev() code had considerable buffering and
was timed favorably compared to stdio for the same amount of data. The
issue in that version was memory usage.

The current unix-format code uses stdio disk-block buffering. Buffering
is not the issue in this version either. The issue is that the current
algorithm is safe at the expense of speed; it spends its time writing the
mailbox update twice. You will see a remarkable difference if you have
/tmp mounted on a ramdisk.

An alternate algorithm, which makes the opposite tradeoff (at user
choice), in in the final stages of development and will be released in a
few days. Among other things, this algorithm skips updates of messages
which have unchanged status and position in the maibox. This algorithm
will probably become the default.

Other algorithms exist, but these algorithms have the flaw that are not
globally suitable. The fundamental problem is the design requirement of
the "set hold" mode on the spool file. A great deal of unnecessary is
work is done on non-spool files because of code that fufills the
requirements of the spool file. This requires interaction with the MTA,
and matters are made worse by the fact that some MTAs have a strict
requirement that the inode of the spool file remain unchanged.

mbx format has no need for either newline conversion or checkpointing.

> So I find it richly amusing to see Crispin talking about mailbox speed
> as a reason to avoid supporting a popular, NFS-safe, crashproof format
> for incoming mail.

For a moderate sized mailbox (2000 or so messages) on a DEC-5000, the
following times are obtained for an IMAP select and fetch-fast:
. mbx requires 1.7 user, 2.6 system, 19 real
. unix requires 8.6 user, 7.7 system, 20 real
. maildir requires 61.8 user, 24.4 system, and 1:45 real

Message data was identical in all three cases.

The additional cost for unix over mbx is message boundary hunting and
newline converstion. The additional cost for maildir over unix is in
filesystem operations: directory scan and per-message stat(), open(), and
close().

The differences become more pronounced as the mailbox increases in size;
as the number of files in a directory increases name/inode translation
(used by stat() and open()) becomes progressively more expensive. These
differences are difficult to measure with a 20 message mailbox, and remain
modest at 200 messages. Message counts of 10,000+ are not uncommon with
administrators.

The chief distinguishing factor of Cyrus is that it uses a proto-database
for just about everything except text fetching. Text fetching is
generally not done in bulk. so the filesystem overhead is kept to
managable levels. Because the proto-database maintains permanent
information that has to be reparsed each session, Cyrus is able to pull
ahead of the c-client supported formats. Maildir lacks such a
proto-database, and furthermore it can't have one and still claim to be
"NFS-safe".

A pure database has the capability of doing even better. I haven't timed
Exchange yet, since Exchange 5.5 has a known performance problem with text
sizes that's fixed in a later version. I hope to have some numbers soon.

And yes, we're looking into offering a pure database format in c-client,
as are other groups.

(Scott Schwartz) Scott Schwartz

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
Mark Crispin <m...@CAC.Washington.EDU> writes:
> For a moderate sized mailbox (2000 or so messages) on a DEC-5000, the
> following times are obtained for an IMAP select and fetch-fast:
> . mbx requires 1.7 user, 2.6 system, 19 real
> . unix requires 8.6 user, 7.7 system, 20 real
> . maildir requires 61.8 user, 24.4 system, and 1:45 real

Are those figures for NFS, or for FFS? A big advantage of maildir is
that it is NFS resistant, and doesn't use file locking (which has
historically been buggy and slow in conjunction with NFS.)

Also, I'd be curious to see the figures for MH. You support that, and
if it turns out to be similar to maildir, then excluding maildir
doesn't seem consistent.


Mark Crispin

unread,
Jun 7, 1999, 3:00:00 AM6/7/99
to
On 7 Jun 1999, Scott Schwartz wrote:
> Are those figures for NFS, or for FFS?

Local file system. Neither NFS nor AFS scale well for high performance
email usage.

> A big advantage of maildir is that it is NFS resistant, and doesn't
> use file locking (which has historically been buggy and slow in
> conjunction with NFS.)

The same holds true for the traditional UNIX mailbox format.

Strictly speaking, it is incorrect to claim that Maildir does not use file
locking. It simply shoves the locking problem down into the underlying
filesystem, at much higher system overhead.

> Also, I'd be curious to see the figures for MH. You support that, and
> if it turns out to be similar to maildir, then excluding maildir
> doesn't seem consistent.

mh is slightly faster; it doesn't have to worry about message filenames
being changed because an external process changed a message status.

The justification for supporting mh (albeit strongly discouraged, and with
crippling restrictions) is that it is a legacy format. Maildir has no
such excuse.

Nor do I have to be "consistant" in what I decide to support. You are
welcome to seek out another IMAP server that supports Maildir. The fact
that there doesn't seem to be any such server should suggest something.

Leslie Mikesell

unread,
Jun 8, 1999, 3:00:00 AM6/8/99
to
In article <Pine.NXT.4.20.990607...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> wrote:

>For a moderate sized mailbox (2000 or so messages) on a DEC-5000, the
>following times are obtained for an IMAP select and fetch-fast:
> . mbx requires 1.7 user, 2.6 system, 19 real
> . unix requires 8.6 user, 7.7 system, 20 real
> . maildir requires 61.8 user, 24.4 system, and 1:45 real

How do they compare when you delete and expunge a message?

My typical action for a mail message is to read and delete it.

I'd prefer not to incur extra overhead while other stuff in
the same file is re-written to release the space.

>The differences become more pronounced as the mailbox increases in size;
>as the number of files in a directory increases name/inode translation
>(used by stat() and open()) becomes progressively more expensive. These
>differences are difficult to measure with a 20 message mailbox, and remain
>modest at 200 messages. Message counts of 10,000+ are not uncommon with
>administrators.

So why not split the difference and allow mail delivery in one
message-per-file formats where (a) locking contention is
avoided (or at least handled correctly), (b) delivery of the
same copy to multiple recipients could be done with links, and
(c) deletion is cheap - then sweep the messages that aren't deleted
after the first access into a format better suited for long term
storage and subsequent access? The second format wouldn't need
to be known by anything else and would have less need to be
NFS safe.

The one-vs.-many messages per file argument always strikes me as
strange when most places have at least at one time run more
volume through news than mail. While it does have scaling problems
it works in the scale most places need for mail.

Les Mikesell
l...@mcs.com

Mark Crispin

unread,
Jun 8, 1999, 3:00:00 AM6/8/99
to Leslie Mikesell
On 8 Jun 1999, Leslie Mikesell wrote:
> How do they compare when you delete and expunge a message?

It all depends upon how many messages are expunged, which in turn depends
upon the quality of your client.

If you always delete a single message, then expunge immediately, then a
one-file/one-message format works better because you avoid the mailbox
rewrite for subsequent undeleted messages in return for the overhead of a
file name lookup and iname removal. But only rotten clients (or foolish
users) behave that way.

In IMAP, typically you delete all the messages that you want to delete in
the session, then expunge the lot of them in a single operation. In this
case, the single file tends to win because:
1) in the one-file/one-message format, you must do an individual file
name lookup and iname removal per message.
2) in the flat file format, you only have to rewrite subsequent undeleted
messages (if any) then do a truncate.

> So why not split the difference and allow mail delivery in one
> message-per-file formats where (a) locking contention is
> avoided (or at least handled correctly), (b) delivery of the
> same copy to multiple recipients could be done with links, and
> (c) deletion is cheap - then sweep the messages that aren't deleted
> after the first access into a format better suited for long term
> storage and subsequent access? The second format wouldn't need
> to be known by anything else and would have less need to be
> NFS safe.

What you then have is use of multiple formats simultaneously (in the same
mailbox too?) -- something you generally want to avoid.

NFS is a poor architectural idea for mail data, and taking a massive
performance hit to be "NFS safe" seems to be a poor choice compared to
having a distributed architecture that doesn't depend upon NFS.

You'd get better benefits by moving to a database and not depending upon
the semantics of a filesystem. A database is also where many of the
advanced facilities of IMAP (e.g. ACLs) lead you; it's really hard to
get ACLs and the UNIX permissions model to play ball with each other.

Chris Stratford

unread,
Jun 8, 1999, 3:00:00 AM6/8/99
to
In article <7jco8i$krd$1...@nnrp1.deja.com>,
vl...@my-deja.com writes:

> Does anyone have docs on getting Qmail and Cyrus working?

Set up Cyrus as normal, then create a .qmail file for each user that
contains something like:

|deliver -a <user> -e <user>

That's all you need.

Chris.

--
Chris Stratford Email: Chris.S...@uk.uu.net
UK Postmaster Voice: +44(0)1223 250690
UUNET Fax: +44(0)1223 250650
An MCI WorldCom Company WWW: http://www.uk.uu.net

Dave Barr

unread,
Jun 8, 1999, 3:00:00 AM6/8/99
to
In article <Pine.NXT.4.20.990607...@Tomobiki-Cho.CAC.Washington.EDU>,

Mark Crispin <m...@CAC.Washington.EDU> wrote:
>Nor do I have to be "consistant" in what I decide to support. You are
>welcome to seek out another IMAP server that supports Maildir. The fact
>that there doesn't seem to be any such server should suggest something.

Sometimes when you fill a vacuum it still sucks.

--Dave
--
http://www.cis.ohio-state.edu/~barr/
ba...@cis.ohio-state.edu

Bennett Todd

unread,
Jun 8, 1999, 3:00:00 AM6/8/99
to
1999-06-07-20:02:43 Mark Crispin:

>For a moderate sized mailbox (2000 or so messages) on a DEC-5000, the
>following times are obtained for an IMAP select and fetch-fast:
> . mbx requires 1.7 user, 2.6 system, 19 real
> . unix requires 8.6 user, 7.7 system, 20 real
> . maildir requires 61.8 user, 24.4 system, and 1:45 real

Youch. Just took me 28 seconds the first time, 4.71 seconds on the second try
real to fire up mutt, read a 4,827 message Maildir folder, paint the screen,
and exit. This is on a K6 at 300MHz (not sure which species of K6), 64MB RAM,
running Red Hat 5.2.

I can see why you wouldn't like Maildir, with the performance tyou enjoy in
your implementation. But for the rest of us, it's plenty fast:-).

-Bennett

Mark Crispin

unread,
Jun 8, 1999, 3:00:00 AM6/8/99
to Bennett Todd
You compared apples and oranges, and drew an incorrect conclusion.

mutt does not do the equivalent of an IMAP "fetch fast on all messages" to
open a Maildir folder and paint an initial screen. This is because mutt
is not an IMAP server. It has everything under its control. It doesn't
have to comply with the demands of external software, no matter how
ridiculous those demands might be.

The problem is that many POP and IMAP clients (including certain ones from
Very Big Vendors) do the evil thing. Some do something even worse, a
"fetch all" or "fetch full" on all messages. This is not something that
the POP or IMAP server can control or prevent.

In order to do an equivalent test with mutt, you need to have it run under
a simulation which will make it paint every message in the mailbox (e.g. a
4900 line screen). Once you have such a simulation in place, then get the
numbers between mbx, unix, and Maildir.

On Tue, 8 Jun 1999, Bennett Todd wrote:
> Youch. Just took me 28 seconds the first time, 4.71 seconds on the second try
> real to fire up mutt, read a 4,827 message Maildir folder, paint the screen,
> and exit. This is on a K6 at 300MHz (not sure which species of K6), 64MB RAM,
> running Red Hat 5.2.
>
> I can see why you wouldn't like Maildir, with the performance tyou enjoy in
> your implementation. But for the rest of us, it's plenty fast:-).

-- Mark --

Martin Bligh

unread,
Jun 9, 1999, 3:00:00 AM6/9/99
to
In article <8glndvn...@galapagos.cse.psu.edu>,

(Scott Schwartz))bio.cse.psu.edu (Scott Schwartz <"schwartz+!usenet%"@> wrote:
>And, not to belabor the obvious, but lots of people *do* use Maildir
>and enjoy acceptable performance. That issue's been decided; now it's
>just a question of which (if any) imap server to run.

Interesting plan to choose your storage format before your mail server ...

>> Third-party Maildir drivers are available; however if you use them it is
>> strictly at your own risk (don't even think about sending in bug reports
>> or complaining about it being slow).
>
>Ironically, pretty much the only complaint that people have about
>maildir is that you won't support it!

Hell, you'd better get a refund for that free software right away.
If he won't give you a check for $0, I'd sue him personally.
How dare he decide what to include, and not to include, in software that
he wrote, and chose to give to you for free. Outrageous.

Martin


Leslie Mikesell

unread,
Jun 9, 1999, 3:00:00 AM6/9/99
to
In article <Pine.NXT.4.20.990608...@tomobiki-cho.cac.washington.edu>,
Mark Crispin <m...@CAC.Washington.EDU> wrote:

>> How do they compare when you delete and expunge a message?

>If you always delete a single message, then expunge immediately, then a


>one-file/one-message format works better because you avoid the mailbox
>rewrite for subsequent undeleted messages in return for the overhead of a
>file name lookup and iname removal. But only rotten clients (or foolish
>users) behave that way.

If it is the server storing the messages in a format where the
most likely action is inefficient, why is it the user who is
being foolish for doing the nomal thing?

>In IMAP, typically you delete all the messages that you want to delete in
>the session, then expunge the lot of them in a single operation. In this
>case, the single file tends to win because:
> 1) in the one-file/one-message format, you must do an individual file
> name lookup and iname removal per message.
> 2) in the flat file format, you only have to rewrite subsequent undeleted
> messages (if any) then do a truncate.

If you read messages often, that still results in frequent deletions.
And, the flat file turns out to be much more complicated in the
common case of deliveries concurrent with the rewrite operation.

>> So why not split the difference and allow mail delivery in one
>> message-per-file formats where (a) locking contention is
>> avoided (or at least handled correctly), (b) delivery of the
>> same copy to multiple recipients could be done with links, and
>> (c) deletion is cheap - then sweep the messages that aren't deleted
>> after the first access into a format better suited for long term
>> storage and subsequent access? The second format wouldn't need
>> to be known by anything else and would have less need to be
>> NFS safe.
>
>What you then have is use of multiple formats simultaneously (in the same
>mailbox too?) -- something you generally want to avoid.

I can see a small amount of programming complexity in presenting
INBOX as a single entity even though you have optimized the storage
for the short and long term components, but I would think eliminating
the contention between deletion write-backs and new deliveries
would be worth it.

>NFS is a poor architectural idea for mail data, and taking a massive
>performance hit to be "NFS safe" seems to be a poor choice compared to
>having a distributed architecture that doesn't depend upon NFS.

Frequently doing complete rewrites of a potentially huge file to
accomplish deletitions and at the same time dealing with locking
issues for competing deliveries doesn't sound so hot either. Even
without NFS considerations the atomic operations of the filesystem
would be a big help here.

>You'd get better benefits by moving to a database and not depending upon
>the semantics of a filesystem. A database is also where many of the
>advanced facilities of IMAP (e.g. ACLs) lead you; it's really hard to
>get ACLs and the UNIX permissions model to play ball with each other.

Once you give up the possibility of using traditional unix
mailbox-file aware mailers, that all comes under the control of
the server and delivery agent with or without any special database
backend. A database might be able to perform better than the
native filesystem, but my experience is that a filesystem is
actually pretty good at storing files as long as you don't
put too many in the same directory, where 'too many' may be
anywhere from several hundred to several thousand depending
on the filesystem and machine. Consolidating the new deliverys
at the time you perform deletions would normally avoid the
scaling problem.

Les Mikesell
l...@mcs.com

Osma Ahvenlampi

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
l...@Mars.mcs.net (Leslie Mikesell) writes:
> If it is the server storing the messages in a format where the
> most likely action is inefficient, why is it the user who is
> being foolish for doing the nomal thing?

The client is. For instance, my IMAP client never does DELETE/EXPUNGE
immediately on a message I mark as deletable. It doesn't even do
DELETE on it immediately because I might be forced to use a more
stupid client occassionally. Instead, it uses a special mark for
"expirable", hides the message from me, and will perform a conditional
DELETE/EXPUNGE for all "expirable" messages over n days old. That
basically means two things: the mailbox contains messages I might have
"deleted" two weeks ago, which is good in case I change my mind and
need to see the message again, and a DELETE/EXPUNGE will be performed
once a day, cleaning up more than one message at a time.

It's both efficient and useful.

> native filesystem, but my experience is that a filesystem is
> actually pretty good at storing files as long as you don't
> put too many in the same directory, where 'too many' may be

Most filesystems are bad at storing files that are not at least
roughly four times the size of the block size on average. A file per
message model not only makes directory operations slower, it also
wastes diskspace and inodes (on filesystems where the maximum number
of files is limited, which is most, if not all, UNIX filesystems).

--
Death: to stop sinning suddenly.

Steve Snodgrass

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
Osma Ahvenlampi <oa-ne...@spray.fi> wrote:
> Most filesystems are bad at storing files that are not at least
> roughly four times the size of the block size on average. A file per
> message model not only makes directory operations slower, it also
> wastes diskspace and inodes (on filesystems where the maximum number
> of files is limited, which is most, if not all, UNIX filesystems).

On the flip side of the coin, there is a potential savings here. Our company
has *lots* of internal mailing lists. This means many users are often
receiving the same message. I wrote a "single store" patch for the Cyrus IMAP
server (which has been previously posted in the newsgroup) that allows Cyrus
to hard-link messages to multiple recipients together. So the "one file per
message" model in that case actually allows us to save lots of disk space and
I/O, since a message to 20 people ends up as one inode with 20 hard links.

Here's a partial listing from my inbox:

-rw------- 1 cyrus mail 2600 Jun 8 15:34 5062.
-rw------- 1 cyrus mail 1071 Jun 9 10:39 5089.
-rw------- 3 cyrus mail 2677 Jun 9 11:45 5096.
-rw------- 3 cyrus mail 33362 Jun 9 13:45 5099.
-rw------- 2 cyrus mail 4079 Jun 9 16:39 5118.

Notice the link counts on the left. I have seen link counts as high as 40 on
our server - the size of sendmail's recipient buffer prevents it from going
much higher since sendmail ends up "chunking" deliveries to lots of
recipients. I could increase that buffer size, but it's probably not worth
the effort.

Of course, as Mark has pointed out, Cyrus also uses index files to get around
the performance penalty imposed by the "one message per file" format. So it
seems that I'm getting the best of both worlds at this point. :-)

--
Steve "Pheran" Snodgrass * ssno...@fore.com * FORE Systems Unix Administrator
Geek Code: GCS d? s: a- C++ US++++$ P+++ L+ w PS+ 5++ b++ DI+ D++ e++ r++ y+*
"I want to take over the world because I'm an egomaniac." --Larry Wall

Leslie Mikesell

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
In article <m3yahsj...@dhcp-144.razorfish.fi>,

Osma Ahvenlampi <oa-ne...@spray.fi> wrote:
>l...@Mars.mcs.net (Leslie Mikesell) writes:
>> If it is the server storing the messages in a format where the
>> most likely action is inefficient, why is it the user who is
>> being foolish for doing the nomal thing?
>
>The client is. For instance, my IMAP client never does DELETE/EXPUNGE
>immediately on a message I mark as deletable. It doesn't even do
>DELETE on it immediately because I might be forced to use a more
>stupid client occassionally. Instead, it uses a special mark for
>"expirable", hides the message from me, and will perform a conditional
>DELETE/EXPUNGE for all "expirable" messages over n days old. That
>basically means two things: the mailbox contains messages I might have
>"deleted" two weeks ago, which is good in case I change my mind and
>need to see the message again, and a DELETE/EXPUNGE will be performed
>once a day, cleaning up more than one message at a time.
>
>It's both efficient and useful.

Yow! You mean the mail store actually has to hold an extra 2
weeks worth of stuff that a person has said they don't ever want
to see again? I'm not sure I consider that a good thing. We
send lots of large attachments around and have other
mechanisms in place to provide backups.

>> native filesystem, but my experience is that a filesystem is
>> actually pretty good at storing files as long as you don't
>> put too many in the same directory, where 'too many' may be
>

>Most filesystems are bad at storing files that are not at least
>roughly four times the size of the block size on average. A file per
>message model not only makes directory operations slower, it also
>wastes diskspace and inodes (on filesystems where the maximum number
>of files is limited, which is most, if not all, UNIX filesystems).

Before you decide that your machine doesn't like putting messages
in single files, ask yourself if you even noticed the fact that
sendmail temporarily stored that same message as 2 files on the
same machine before it was delivered to the mailbox. I've
never seen anyone mention that as a performance problem. The
problem you do see, as with news, is letting vast numbers of
files accumulate in a single directory, which is why I suggest
sweeping the new deliveries into a more efficient long term
storage format as soon as you see that they are likely to be
around a while (i.e. they aren't deleted after the first reading).
A large percentage of our email goes to multiple recipients
(interest group, work group, department, whole company) and
it would be a big win to be able to deliver a single copy
with hard links into the other directories. The sweep into
another storage format might consider the link count in
deciding which way is actually more efficient.

Les Mikesell
l...@mcs.com

Mark Crispin

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to Steve Snodgrass
On 10 Jun 1999, Steve Snodgrass wrote:
> Of course, as Mark has pointed out, Cyrus also uses index files to get around
> the performance penalty imposed by the "one message per file" format. So it
> seems that I'm getting the best of both worlds at this point. :-)

Right. One disadvantage of a database (or proto-database such as
Cyrus) is that you lose the ability to access the data outside of POP or
IMAP, because the data can not be owned by an individual user.

You could, in theory, hack up Cyrus to run that way (I don't know how hard
it would be) but that would preclude your use of hard links to share the
data. In my opinion, hard links are the obvious thing to do and I'm
surprised that Cyrus doesn't do it as standard practice.

Lyndon Nerenberg

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
Mark Crispin <m...@CAC.Washington.EDU> writes:

> In my opinion, hard links are the obvious thing to do and I'm
> surprised that Cyrus doesn't do it as standard practice.

If you inject using the deliver program, you never get more than
one recipient address per injection[*], so you can't hard link even
if you want to. We didn't add hard links to our server until we
switched over to LMTP as the default delivery model.

Even with our current server, if you use the deliver command supplied
with it to do delivery, you don't get hard links. C'est la vie.

[*] Unless you run using a very insane configuration ...
--

The two most common elements in the universe are Hydrogen and stupidity.
-- Harlan Ellison

Rupa Schomaker

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
l...@Venus.mcs.net (Leslie Mikesell) writes:

> Yow! You mean the mail store actually has to hold an extra 2
> weeks worth of stuff that a person has said they don't ever want
> to see again? I'm not sure I consider that a good thing. We
> send lots of large attachments around and have other
> mechanisms in place to provide backups.

We use the same client (emacs+gnus). You can choose how long these
messages are in limbo and you can also set complex rules for which are
expired sooner than others (really). Say I want to hold messages from
my boss for 2 weeks but want to expire messages from the noisey jokes
list immediate -- I can. IMAP by itself doesn't offer this
flexibility.

Oh, and the messages aren't gone for good, you tell your MUA to show
you these "expired but not deleted" messages. If you want to
explicitly delete a message (and not go through the expire phase) then
there is a mark for that as well (B-del).

> Before you decide that your machine doesn't like putting messages
> in single files, ask yourself if you even noticed the fact that
> sendmail temporarily stored that same message as 2 files on the
> same machine before it was delivered to the mailbox. I've
> never seen anyone mention that as a performance problem.

Umm... Actually it is a big problem with high volume sites. Thats why
many of us run something else like PostFix or qmail.

> The
> problem you do see, as with news, is letting vast numbers of
> files accumulate in a single directory, which is why I suggest
> sweeping the new deliveries into a more efficient long term
> storage format as soon as you see that they are likely to be
> around a while (i.e. they aren't deleted after the first reading).
> A large percentage of our email goes to multiple recipients
> (interest group, work group, department, whole company) and
> it would be a big win to be able to deliver a single copy
> with hard links into the other directories. The sweep into
> another storage format might consider the link count in
> deciding which way is actually more efficient.

No disagreement there...

--
-rupa

Steve Snodgrass

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
Lyndon Nerenberg <lyn...@messagingdirect.com> wrote:
> If you inject using the deliver program, you never get more than
> one recipient address per injection[*], so you can't hard link even
> if you want to. We didn't add hard links to our server until we
> switched over to LMTP as the default delivery model.

Yes, but Cyrus deliver supports LMTP, so there's no reason not to hard link if
you're in LMTP mode, which is what my patch does. It's true that there's no
reasonable way to support hard links without using LMTP, though.

Bennett Todd

unread,
Jun 10, 1999, 3:00:00 AM6/10/99
to
1999-06-09-21:39:37 Martin Bligh:

>Interesting plan to choose your storage format before your mail server ...

How so? I tend to specify things in roughly descending order of how hard they
are to change. The basic nature of the OS comes first --- Unix. Next you
need to choose the data store --- migrating from one to another is generally
more disruptive than any other change, and the nature of the data store is
going to define the limits on possible growth plans (e.g. buy a horking big
switch and a couple of months production output from Netapp and serve email
to all carbon-based life forms on earth:-). Once you've picked the data store
(Maildir) the particular platform comes next; these days, likely a hotrod PC
with Linux; up until a couple of years back it'd have been a Sun w/ Solaris
2.5 or better; prior to that it'd have been a Sun with SunOS 4.x. Once we've
settled the platform, then you shop for the daemon whose feature set comes
closest to meeting your needs for today. If you've made good choices for the
earlier (harder to change) parts of your decision process, the actual precise
server should be an interchangable part --- and if you've designed to scale to
multiple-of-everything, you might not even need to be running the same server
on all boxes.

-Bennett

Leslie Mikesell

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
In article <m37lpb6...@gw.rupa.com>, Rupa Schomaker <ru...@rupa.com> wrote:

>> Before you decide that your machine doesn't like putting messages
>> in single files, ask yourself if you even noticed the fact that
>> sendmail temporarily stored that same message as 2 files on the
>> same machine before it was delivered to the mailbox. I've
>> never seen anyone mention that as a performance problem.
>
>Umm... Actually it is a big problem with high volume sites. Thats why
>many of us run something else like PostFix or qmail.

It isn't the volume that gets you, it is the number that you can't
deliver immediately causing a large number files to accumulate
in the queue directory at one time. You won't see this problem
on local deliveries where they don't accumulate, and you could
avoid it on a one-message-per-file delivery by letting the IMAP
server move/remove the files instead of letting them accumulate.
If you have people using POP, it would take care of itself.

Les Mikesell
l...@mcs.com

Osma Ahvenlampi

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
l...@Venus.mcs.net (Leslie Mikesell) writes:
> Yow! You mean the mail store actually has to hold an extra 2
> weeks worth of stuff that a person has said they don't ever want
> to see again? I'm not sure I consider that a good thing. We

Well, I can configure the expiry period on a per folder basis. And I
very rarely have any reason to say I don't ever want to see a message
again. Instead, I say that I have no reason to keep this around for
longer than, depending on the folder, one week to three months. Until
then, it's kept around just in case, and then it goes away without
further action from my part.

The extremely nice thing about it, that I think in the long run SAVES
disk space, is that since I know mail will get cleaned up after it
loses relevance, but not before, I don't have to care about it
myself. I never have to "clean up my INBOX" by hand - many people I
know, most in the place I work, have INBOXes of 2000 messages or more,
mostly because they couldn't delete something immediately and going
back to do so later is too time-involving to do very often (or ever,
as is the case for some). In comparison, my INBOX has less than 500
messages, and has been so for many months. New stuff comes in, but old
stuff gets expunged at about the same rate.

> Before you decide that your machine doesn't like putting messages
> in single files, ask yourself if you even noticed the fact that
> sendmail temporarily stored that same message as 2 files on the
> same machine before it was delivered to the mailbox. I've

> never seen anyone mention that as a performance problem. The

Heh. Sendmail is a huge performance problem, although not necessarily
because of that. You have to realize though that sendmail's queue
serves a totally different purpose than a mail folder - it's
explicitly transitionary data.

A better example is news storage. For years, news servers have stored
every message in a separate file. It's nice for crossposts, but wastes
amazing amounts of space and needs a huge amount of processing
otherwise (profile the expiry process on an INN 1.x system
sometime). Recently, however, high-performance NNTP servers have
started to appear that store all the messages in each group per one
day into a single file that saves a lot of partial blocks and is much
faster to process.

--
Left to themselves, things tend to go from bad to worse.

Martin Bligh

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
In article <slrn7m0ff...@newritz.mordor.net>,

If I wanted a mail 'solution', I'd specify what I wanted it to be able to
do, then go find an application that did it, then choose the OS, then the
hardware. Perhaps one of the original criteria for the application might be
that it runs on UNIX, as there's only expertise on that particular OS within
the organisation.

Why would migrating to a different mailstore format be 'more disruptive than
any other change'? I would have thought the most disruptive change is anything
that requires you to change your email client. If you wanted to move from,
say, POP3 to IMAP, you may have to force all your users to move client
application. Now *that's* disruptive! Changing mailstore should be completely
tranparent to the end user - just requires a conversion tool / script.

My criteria for choice went something along the lines of "must store on
a central server, accessible from everywhere, always keep mail on the server,
and be able to file under different mailboxes on the server, client must
be distructible / changable without any loss of email". The only open standard
that I could find that would do this was IMAP. Thus I wanted an IMAP server.

I really don't care what the backend mail store is - as long as the format is
published, and / or it's accessible to IMAP, I can always convert formats if
I want to. Use whatever makes sense for performance / backup / whatever.

Nor can I understand why anyone would want to access their mailboxes over NFS
when they already have IMAP (as far as I recall, that's how this thread
started, and why people want Maildir). What's the point of implementing a
client-server protocol, then introducing another massive layer of complexity
beneath it, which you don't need?

Martin.


Chris Barrera

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
Because an administrator might still want the server's mail store to exist
on an NFS server even if the sole thing that accesses it is the IMAP server.
Sometimes one will want to separate storage from the host CPU, on a higher
availibility system. If the server host crashes and burns, it is easy to
have a standby system take over within minutes without the mail store itself
being unavailable. Sort of the cheap "high availibility" solution.

There are undoubtedly many other reasons to have the mail store accessible NFS,
say in a mixed IMAP/NFS environment where some users use IMAP and others do
not. I admit this is stupid, but Sun writes their dtmail IMAP client and
their IMAP server support this type of environment. There are even some
weird behaviors that result from this I won't even go into right now...

Chris Barrera
cbar...@msp.sc.ti.com

Martin Bligh <mbl...@sequent.com> wrote:
: Nor can I understand why anyone would want to access their mailboxes over NFS

Mark Crispin

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
On 11 Jun 1999, Chris Barrera wrote:
> Sometimes one will want to separate storage from the host CPU, on a higher
> availibility system. If the server host crashes and burns, it is easy to
> have a standby system take over within minutes without the mail store itself
> being unavailable. Sort of the cheap "high availibility" solution.

"Cheap" is a good way of describing it. I would not use certain other
adjectives, e.g. "inexpensive", "robust", "high performing".

> There are undoubtedly many other reasons to have the mail store accessible NFS,
> say in a mixed IMAP/NFS environment where some users use IMAP and others do
> not. I admit this is stupid, but Sun writes their dtmail IMAP client and
> their IMAP server support this type of environment.

I heard that this was over the vehement and frantic objections of the IMAP
software developers at Sun...

I've never met anyone who does IMAP server development and considers NFS
to be a suitable back-end store for an IMAP server, but I've met several
who commiserate about the horrors of such a thing. It's a good topic for
war stories in the hotel bar... ;-)

Andrew Lochart

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
Chris Barrera wrote:
>
> Because an administrator might still want the server's mail store to exist
> on an NFS server even if the sole thing that accesses it is the IMAP server.
> Sometimes one will want to separate storage from the host CPU, on a higher
> availibility system. If the server host crashes and burns, it is easy to
> have a standby system take over within minutes without the mail store itself
> being unavailable. Sort of the cheap "high availibility" solution.

True, but why not just set up an IMAP server with high-availability host
(redundant, hot standby CPUs) attached to the disk subsystem? You get
your inexpensive HA and avoid the problems asscoiated with NFS.

Cheers,
Andrew

--
Andrew Lochart Director, Customer Marketing Mirapoint, Inc.
and...@mirapoint.com http://www.mirapoint.com +1-408-517-1326


Mark Crispin

unread,
Jun 11, 1999, 3:00:00 AM6/11/99
to
On 12 Jun 1999, Martin Bligh wrote:
> Intuition (with no empirical evidence to back it up) would lead me to
> suspect that IMAP is mostly IO based, not CPU intensive

This is our experience at UW with our server, and it's even more the case
with Cyrus.

> and thus you'd
> save very little load (if any) on the server by using NFS rather than
> IMAP straight from it.

Yup. I can't believe how many people think that they'd "get better
performance" by having a rack of IMAP server CPUs talking to a single NFS
filesystem.

Then there's the folks who think that they'll "get better reliability",
although it bewilders me why an IMAP server CPU is any more likely to
crash than an NFS server CPU.

As best as I can understand, their thinking goes like this:

Assume that there are 10 CPUs. With 9 IMAP server CPUs going to one NFS
server CPU, the failure of a single CPU has a 90% of simply taking out one
IMAP server IP address but not shutting down availability for anyone.
There is, however, a 10% chance of a CPU failure shutting down
availability for everyone.

With 10 IMAP server CPUs, each with their own disk and user communities,
the failure of a single CPU will take out service to 10% of the user
community.

Our feeling is that (1) we do our damnedest to reduce CPU failures to as
close to zero as we can, and (2) we'd rather have a little failure to deal
with, than run the risk of a catastropic failure.

Martin Bligh

unread,
Jun 12, 1999, 3:00:00 AM6/12/99
to
In article <7jrsla$rro$1...@tilde.csc.ti.com>,

Chris Barrera <cbar...@melon10.msp.sc.ti.com> wrote:
>> Nor can I understand why anyone would want to access their mailboxes over
>> NFS when they already have IMAP (as far as I recall, that's how this
>> thread started, and why people want Maildir). What's the point of
>> implementing a client-server protocol, then introducing another massive
>> layer of complexity beneath it, which you don't need?
>
>Because an administrator might still want the server's mail store to exist
>on an NFS server even if the sole thing that accesses it is the IMAP server.
>Sometimes one will want to separate storage from the host CPU, on a higher
>availibility system. If the server host crashes and burns, it is easy to
>have a standby system take over within minutes without the mail store itself
>being unavailable. Sort of the cheap "high availibility" solution.

So ... you shift the single point of failure from the IMAP server to
the NFS server, and introduce a pile of complexity, and an ugly manual
failover? Not sure I follow the logic behind this ... are you saying you
can only afford one reliable machine, and aren't willing to run the IMAP
server on it?

Intuition (with no empirical evidence to back it up) would lead me to

suspect that IMAP is mostly IO based, not CPU intensive, and thus you'd


save very little load (if any) on the server by using NFS rather than

IMAP straight from it. The only other reason that springs to mind not
to run IMAP straight from the server is security concerns, but then if
you're running NFS, I don't think you're in much of a position to throw
stones ;-)

So I'm still not sure why you wouldn't run IMAP straight from what is now
your NFS server ... ??? Still a single point of failure either way.
(assuming all along that you don't want to shell out for a clustered machine
with shared disk).

Martin.

Chris Barrera

unread,
Jun 12, 1999, 3:00:00 AM6/12/99
to

Oddly enough I don't run IMAP as yet ;)

The motivation I see for using a separate NFS server for the mail store
is to have multiple MX hosts that can deliver into the same mail spool,
say if one loses its marbles the other takes over. That is the reason for
spending the money on a higher availibility NFS server and perhaps using
cheaper but still reasonably sturdy equipment to run sendmail. If the NFS
server it a Network Appliance system, then should somehow, if ever, mailbox
corruption does occur, then an earlier version of the mailbox can be
retrieved from read-only snapshots performed automatically by the filer
itself. This is on top of RAID protection, and of course, backups.

Is it truly worth it? I am sure this itself would make for good discussion,
especially since NFS is such an evil beast in many minds around here ;) I
can say, however, that in 4 years of such an operation I have never seen
mailbox corruption due to NFS locking problems. In fact, mailbox corruption was
always a rare event, and the only times it happened we were able to attribute
it to the user running multiple mail-readers at the same time. This is on a
network of hundreds of UNIX workstations and a few thousand users...

However, when in the future I start running an IMAP server I certainly do
intend to remove all NFS client access to the spool. Security is the main
concern and I still don't like having hundreds of client workstations
and user mail access having such reliance on NFS availibility and performace
to said workstations. I still ponder the possibility of having, say, two
IMAP servers each able to access the same mail store on an NFS server. I
know what I will hear from many vocal and notable people in this newsgroup,
NFS is evil in every circumstance. While I don't doubt others experience,
I have yet to see such nasties for myself. I never discount the possibility
of course, I still do everything possible in the environment to minimize
problems. But if people say this isn't robust, then I say that perhaps
many people haven't exercised enough control over their environment.

Even Oracle under certain circumstances supports the database store being
on one NFS server and the actual database server processes running on another
CPU host. So why not IMAP?

Chris Barrera
cbar...@msp.sc.ti.com

Martin Bligh <mbl...@sequent.com> wrote:
: In article <7jrsla$rro$1...@tilde.csc.ti.com>,

(Scott Schwartz) Scott Schwartz

unread,
Jun 14, 1999, 3:00:00 AM6/14/99
to
Mark Crispin <m...@CAC.Washington.EDU> writes:
> I've never met anyone who does IMAP server development and considers NFS
> to be a suitable back-end store for an IMAP server, but I've met several
> who commiserate about the horrors of such a thing. It's a good topic for
> war stories in the hotel bar... ;-)

Look, that's not the point. This isn't about imap, or about
performance. It's about your c-client library. Your mail
applications support MH, but Maildir is just as good, so why not
support that too?


(Scott Schwartz) Scott Schwartz

unread,
Jun 14, 1999, 3:00:00 AM6/14/99
to
Mark Crispin <m...@CAC.Washington.EDU> writes:
> As best as I can understand, their thinking goes like this:
>
> Assume that there are 10 CPUs. With 9 IMAP server CPUs going to one NFS
> server CPU, the failure of a single CPU has a 90% of simply taking out one
> IMAP server IP address but not shutting down availability for anyone.
> There is, however, a 10% chance of a CPU failure shutting down
> availability for everyone.

As I understand it, the thinking is,

Assume that there are 10 CPUS. With 4 IMAP server CPUs going to 6 NFS
server CPUS, the failure of a single NFS CPU isn't so bad, and it's a
lot more flexible than using local filesystems for everything,
especially since IMAP isn't our favorite access method anyway.

But that's not the point. The point is, you support MH folders,
so why not Maildir folders too?


(Scott Schwartz) Scott Schwartz

unread,
Jun 14, 1999, 3:00:00 AM6/14/99
to
Mark Crispin <m...@CAC.Washington.EDU> writes:
> On 7 Jun 1999, Scott Schwartz wrote:
> > Are those figures for NFS, or for FFS?
>
> Local file system. Neither NFS nor AFS scale well for high performance
> email usage.

But, see, you posted numbers for the wrong scenario, in order to back
up one of those "doesn't scale" assertions. Why not run the right
experiment?

Anyway, the fact is that they do scale more than well enough for the
usage a lot of people care about, so you can't just wish them away
like that.

> > A big advantage of maildir is that it is NFS resistant, and doesn't
> > use file locking (which has historically been buggy and slow in
> > conjunction with NFS.)
>
> The same holds true for the traditional UNIX mailbox format.

Yes, maildir enjoys benefits in both cases, but in the NFS case you
have to do locks over the network, which is slower, and magnifies the
effect.

> Strictly speaking, it is incorrect to claim that Maildir does not use file
> locking. It simply shoves the locking problem down into the underlying
> filesystem, at much higher system overhead.

It doesn't use flock, or lockf, or fcntl. Is rename really more
expensive? It's certainly less buggy, in the network case.

> > Also, I'd be curious to see the figures for MH. You support that, and
> > if it turns out to be similar to maildir, then excluding maildir
> > doesn't seem consistent.
>
> mh is slightly faster; it doesn't have to worry about message filenames
> being changed because an external process changed a message status.

folder -pack
sortm

> The justification for supporting mh (albeit strongly discouraged, and with
> crippling restrictions) is that it is a legacy format. Maildir has no
> such excuse.

Hmm.

> Nor do I have to be "consistant" in what I decide to support. You are
> welcome to seek out another IMAP server that supports Maildir. The fact
> that there doesn't seem to be any such server should suggest something.

The truth is that I couldn't care less about imap (I already have an
authenticated network filesystem, thanks), but since you also produce
pine, which some of my friends use, I thought it would be worth
broaching the issue.


Sasha Mikheev

unread,
Jun 14, 1999, 3:00:00 AM6/14/99
to
On Fri, 11 Jun 1999 21:43:05 -0700, Mark Crispin <m...@CAC.Washington.EDU> wrote:
>On 12 Jun 1999, Martin Bligh wrote:
>
>Yup. I can't believe how many people think that they'd "get better
>performance" by having a rack of IMAP server CPUs talking to a single NFS
>filesystem.
It is fact for POP3 servers. I expect it to be the same for the IMAP.
It allows separate machines to act as POP3, IMAP or MX servers. Such
separation of services is a very good idea. It allows better tuning
and in case that one service goes down the rest is still running.

CPU is the issue too. Multiple processes simultaneously writing
to disk will rise load quite a bit.

>
>Then there's the folks who think that they'll "get better reliability",
>although it bewilders me why an IMAP server CPU is any more likely to
>crash than an NFS server CPU.

You use NFS servers which rarely crash and reboot fast. Such as
Netapp filers. They reboot under 2 minutes, rarely crash and have
other nice features such as snapshots. Also newer filers have a
failover options.

Another issue here is price performance. NFS setup scales horizontally
very well. The largest investment is a good NFS server. For cpu nodes
commodity workstations can be used. In my opinion alternatives are
going to be more expensive and more difficult to manage.

>
>As best as I can understand, their thinking goes like this:
>
>Assume that there are 10 CPUs. With 9 IMAP server CPUs going to one NFS
>server CPU, the failure of a single CPU has a 90% of simply taking out one
>IMAP server IP address but not shutting down availability for anyone.
>There is, however, a 10% chance of a CPU failure shutting down
>availability for everyone.
>

You presume that the chance of NFS server going down are the same as
the CPU node. In my expirience this is not true.

--
Sasha Mikheev Linux -- put a penguin in your processor

System Manager at Netvision Israel, Ltd
Tel +972-4-8560600
http://aldan.netvision.net.il/~sasha

Joachim Achtzehnter

unread,
Jun 14, 1999, 3:00:00 AM6/14/99
to
"schwartz+!usenet%"@((Scott Schwartz))bio.cse.psu.edu (Scott Schwartz) writes:
>
> But that's not the point. The point is, you support MH folders,
> so why not Maildir folders too?

If you read the whole thread you will find that he has answered this
question already! MH may be (almost) as bad as Maildir in Mark's
opinion, but it is an old, traditional format, hence it is
supported. Maildir is a newcomer, and Mark doesn't want to encourage
yet another bad format.

Joachim

--
joa...@kraut.bc.ca (http://www.kraut.bc.ca)
joa...@mercury.bc.ca (http://www.mercury.bc.ca)

Mark Crispin

unread,
Jun 14, 1999, 3:00:00 AM6/14/99
to Scott Schwartz
On 14 Jun 1999, Scott Schwartz wrote:
> But that's not the point. The point is, you support MH folders,
> so why not Maildir folders too?

Maildir requires an ongoing investment of a significant amount of
resources that are not available at UW. I have a long list of programming
and support project that need to be done that are considerably more
important than crank ideas of what constitutes a mail store.

An organization that wanted MH paid me, personally, a substantial sum of
money to use my own free time to add and support MH to the public c-client
sources. MH would not be offered or supported otherwise.

Maildir has a significant additional support burden above and beyond MH.
One source of additional burden are people who waste my time by arguing
and demanding that I give them something for free.

Jeff Hayward

unread,
Jun 15, 1999, 3:00:00 AM6/15/99
to
In article <7jrppi$p...@scel.sequent.com>,

Martin Bligh <mbl...@sequent.com> wrote:
>Nor can I understand why anyone would want to access their mailboxes over NFS
>when they already have IMAP (as far as I recall, that's how this thread
>started, and why people want Maildir). What's the point of implementing a
>client-server protocol, then introducing another massive layer of complexity
>beneath it, which you don't need?

Reliability, performance and scalability. We can add filers as
needed, we can add IMAP/POP/SMTP frontends as needed. We can fail or
replace a filer or frontend with minimal disruption. We don't have to
go building incredibly expensive monolithic systems just to do email.
The NetApp filer's performance is better than that of local file
systems for our workload.

We (U. Texas) use NetApp filers, intel boxes running BSD/OS, the UW
suite, and qmail to store about 5.5 million (maildir) messages for 80K
mailboxes, with about 500K deliveries per day.

This is the 6th hardware generation of this mail service and the
first to use maildir storage. It is by far the most reliable, best
performing, most scalable configuration we've yet used.

We have used the UW c-client based apps for many years (going on 10, I
think) and greatly appreciate the work and good will of the author.
The existence and continued development of the c-client based apps has
been incredibly valuable to us. We have made some performance
enhancements to the maildir module that are currently not in shape for
use outside our specific environment. I would be motivated to rework
them for wider use if there were any likelyhood that they would be
adopted. That said I don't knock MRC's desire to avoid adding
anything he dislikes to the c-client library. That's clearly his to
decide.

But I want to go on record - we and more than a few others I know of
disagree with MRC on the utility of scalable mail services built
around this paradigm. Mark, if you don't know anyone who has good
things to say about it I think you must not be talking to a
significant part of the enterprise and ISP world.

Regards,
-- Jeff Hayward
--
Jeff Hayward J.Ha...@ots.utexas.edu
UT System/OTS +1 512 471 2432 (v)
UT Austin/ACITS +1 512 471 2449 (f)

Carl S. Gutekunst

unread,
Jun 16, 1999, 3:00:00 AM6/16/99
to
>> There are undoubtedly many other reasons to have the mail store accessible
>> NFS, say in a mixed IMAP/NFS environment where some users use IMAP and
>> others do not. I admit this is stupid, but Sun writes their dtmail IMAP
>> client and their IMAP server support this type of environment.
>
> I heard that this was over the vehement and frantic objections of the IMAP
> software developers at Sun...

Yep. It was mandated by an internal Sun review committee. The whole issue
came up when we foolishly noted in our documentation that running your Inbox
on an NFS mount is not robust, and was not supported by our IMAP server. The
review committee responded that Sun had been NFS mounting mailboxes for years,
and mandated that we fix the "problem" in our IMAP server. We responded that
NFS access to /var/mail had been non-robust forever, and we didn't introduce
this problem, we just documented it. They responded that they didn't care
whose fault it was, they just wanted Inbox access over NFS to be robust.

So we implemented changes in our locking and a variety of other loose ends,
and documented what we did so that other groups in Sun could make compatible
changes to their /var/mail applications. The only one that did so was DtMail.

<csg>

Carl S. Gutekunst

unread,
Jun 16, 1999, 3:00:00 AM6/16/99