On 9/27/01 11:56 PM, "David Thornton" <dthorntoncorp.attcanada.ca> wrote:

> I am talking about kernel RAMDISKS there, not solid state disks. I would
> have to agree that the ide interface would probably be a big bottle neck.

The solid state will be slower, but the kernel RAMDisk takes memory away
that could otherwise be used for other processes, limiting your parallelism
in delivery. The solid state disk, on the other hand, would be less likely
to lose data on a crash and can be UPSed, so you have some protection from
system failure. Basically, there's no right answer here, just a bunch of
things you can trade off against each other depending on what you think is
best.

> I think you could set the transport for "defered" to a relay host that is
> just another instance running on the same server (on a different interface)
> that is using a proper disk for queues.
>
> anyone care to comment?

I'd say it'd be easier to build a tool that walks the queues and moves
batches, rathe than try to futz postfix into a hack to do it. That way you'd
have better control, anyway. I've done that using sendmail (although I've
found that setting a longer wait-between-retries and using a bushy
queue-structure makes the need to do that go away; if I were still doing
RAMdisk stuff, it might be different) and it's quite reasonable. Just make
sure whatever tool you build uses the same locking protocols so you don't
step on each other in the queues.

-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]