Quoting Marc Perkel ([EMAIL PROTECTED]): > Suppose Exim had 2 queues instead of one. We'll call the first queue the > primary queue which is a ram drive and the secondary queue which is a > disk drive. All this is of course optional and user settable.
Having queues in ram is, as i pointed out in my earlier posts about 'large exim setups', a workaround for Exim's (rather poor) way of handling large queues. I would *not* opt for a configuration option to store the queue in ram, as this can easily be configured with some tricks, and it still is a workaround for a problem instead of a solution. Other MTA's -can- manage large queues, and for what i know, without storing them in ram with the risk of losing data. Stop focussing on ramdrives and queues in memory, instead, focus on -why- it is Exim is slow with large queues. These are just my $0.02 -Sndr. -- | Support bacteria. They're the only culture some people have. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
