At 1:44 PM -0400 5/30/01, rick pim wrote:
> the most obvious performance wins are server mode and fast-update.
> fast-update is listed in the manual as potentially breaking biff.
> if this is the worst problem then, given our setup, i'm more than willing
> to enable it. are there any other consequences to using fast-update?
Shouldn't be any (other than the shell's "you have new mail"
feature) unless you have programs that "know" the i-node of the
spool file.
>
> the same holds for server mode: in a sitation like this, there are
> potential issues with server mode, but the documentation doesn't
> detail them. exactly how serious _are_ they? what's the worst case?
> is it something serious (lost mail, vanishing mailboxes) or just
> cosmetic?
Worst case is spool corruption. This could occur if the shell user
is messing with the spool file during a POP session. Just to be
clear: shell access itself isn't a problem. It's mentioned as a
potential contraindication for server mode because it provides the
opportunity for the user to muck with the spool directly. Even
altering the spool directly isn't necessarily a problem, but if
done during a POP session in server mode, you've got corruption.
>
> other performance wins in v4 would be nice to hear comments on.
Server mode is a *lot* faster during initial mail checks if no new
mail has arrived since the last mail check.
Chunky-writes may be faster or slower, depending on your network
(if it's congested, chunky-writes may be slower).
