Greg Earle <[EMAIL PROTECTED]> writes: > But we have these few recalcitrant users who don't seem to know that "Keep > Messages On The Server" is bad. Really Bad. Especially when these few > people have mail spool files that are over 50 Mbytes in size. Some of > them even closer to 100 Mbytes (or over).
IMHO users do this not because they're trying to be butt-heads, but because they're trying to get work done. If their mail is sitting on their desktop at work, they can't access it on the road. Etc. > Naturally, every time these people POP in, the system goes into complete > I/O and CPU starvation mode as all cycles get used up copying their huge > mail spools to /var/mail/.luser.pop and then back again to /var/mail/luser. Is this just when a user deletes a message? Or even when they just read a message (does the pop server have to touch the message content to update attributes like Status?). Either way, expensive I admit. If the spool and temp file are on the same filesystem, you should be able to avoid the "copy" back to the original file: a UNIX rename() should be fine and is a "atomic" under UNIX (is a single fast operation, either succeeds completely or fails completely). So you avoid the second block-by-block disk read and write which hits the same disk twice for ever block. Should help performance. But I don't know if the code works this way or not. Note that this is NOT atomic if you have the two files on different filesystems.
