I may be revealing my ignorance again, but I think we were using qpopper before we even decided to use IMAP at all, that had problems over NFS because it locks, makes a copy and if you are saving messages on the server copies it back. All that happening over NFS doubled our I/O requirements. cucipop doesn't make a copy so we began to use it. Shortly thereafter we decided to also include IMAP access to "reduce POP I/O traffic" and now IMAP access has become a value-added service.
It sounds to me as if you folks are thrashing about trying different things to see what will work, but for some reason have chosen to ignore (or reject) advice from sites which have made things work.
In my opinion, your fundamental system architecture is fatally flawed; and you are doomed to repeat this thrashing until you change the architecture to one that is not so flawed.
Quite frankly, you would be better off than you are now if you got rid of all those CPUs and running everything on what is now the NFS server. You are not gaining any benefit from the additional CPUs, and the introduction of NFS significantly hurts matters. I doubt very much that Lustre will remedy the NFS issues, much less address the fundamental flaws in the architecture.
I'll have to look in to ipop3d. Does it make a temporary working copy, and then write back to the mbox when it is done?
No.
does it have a mailing list on which it would be more appropriate to discuss these things?
Perhaps the [EMAIL PROTECTED] mailing list.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
