At 08:43 AM 7/18/2005, Adam Goryachev wrote:
reiserfs is supposed to handle this case much better, also supposed to handle large numbers of small files (ie, email) better... My opinion is that after a few hundred thousand files in the one directory, it will still be slow... although it's probably still faster than ext2 :)
well, i don't run linux for anything mission critical. the AS/AV server is freebsd. i only wish fbsd had a usable journaling filesystem (djb specifically rejects soft updates for queue partition - i suppose i could branch that off separately).
Yes, I had (and still have) this problem to some degree... Although, I wonder why you have such a setup? It would seem that you have multiple MX servers for redundancy/load balancing (?), yet you put the entire load of AV + Anti-Spam (AS) onto a single box. I would have thought it would be better to have the AV + AS on each of the 4 MX, who would write directly to the maildir's, or, smtproute to your other server which writes to the maildir but doesn't really need to do any load intensive work (eg AV/AS)... Could you tell me why you chose to do things in this way ?? (For my own education/enlightement, I've been slowly working towards putting AV + AS on each MX (done) and was about to work on pointing each MX at a single NFS mounted maildir for final delivery. Then the pop/imap server would also access the NFS mounted maildir. I still see a number of emails that are accepted by my secondary MX, and then rejected by the primary, I assume the secondary MX's bayes DB is not as good or something....
i want my MX servers to accept incoming mail without any delay, ever. I use older, relatively 'slow' hardware for my MXes, so i want them to do nothing but accept inbound mail from the net at large. i have a once-per-minute cronjob that watches the queues, and if they become large, i'm paged, and at the same time, the smtproutes are changed to point the mail directly to the popserver so that mail will keep flowing. it's imperfect, but it works. the proxy works great, it's 'fast' hardware and handles the load from all four MXes okay.
Well, I did that for a while, but I didn't like silently quaranting emails without telling either sender/recipient, and I certainly didn't see the point of telling the recipient about every spam email I blocked. so I finally just implemented the rejection method. Hopefully, in most cases, the spammer's mail never goes anywhere (if they send it direct), unfortunately, there may be cases where an open relay is sending it, in which case some unfortunate person may get spammed (at least it isn't my client, sounds mean, but there isn't really any perfect solution)....
99% of the junkmail we get uses either a bogus reply address and is coming from a zombied PC - so notifying just generates more junkmail and rejecting is ignored - or, likewise, we're the recipient of collateral mailbombs from sites bouncing junkmail from zombied PC's that are using fake email addresses at *our* domains. so either way, bounces suck, rejection is nice, but i'd rather silently shitcan junk and risk the (extremely rare) false positive that doesn't get notified.
Paul Theodoropoulos http://www.anastrophe.com http://www.smileglobal.com ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Qmail-scanner-general mailing list Qmail-scanner-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
