On Fri, 7 Apr 2006, Edward Chase wrote:
> The snippet below from a previous email gives me the impression that it
> could help me with with an issue I'm having here with users quotas.
It was my problem, and it doesn't seem to be as bad as it was.
>
> My current scenario...
>
> * /var/mail holds the users mailboxes (and is it's own filesystem).
> * /var/spool/poptemp is qpopper's scratch area, I'm assuming this is the
> "temp-drop".
Is this actually on another spindle/drive altogether? If it's on the
same one then it offers no advantage, in terms of head seeks.
Discussed in that thread.
> * My users have a quota on /var/mail.
> * Assume a user is at his limit then check email.
> * /var/mail/user is moved to /var/spool/poptemp/.user.pop by qpopper
> (filesytem quota on /var/mail is now zero)
> * sendmail now moves email from delivery queue into /var/mail/user
Ouch.
> * qpopper is done and attempts to move /var/spool/poptemp/.user.pop back to
> /var/mail/user, but can't because the new mail that is in /var/mail/user
> plus the old mail in /var/spool/poptemp/.user.pop is too much for the quota
> on /var/mail. Yes, the user is leaving mail on server (grrrr...)
> * now the user has mail data in two places and the thing just keeps getting
> worse as the user checking email will allow the file in the temp-drop to
> grow. (Now I'm thinking to myself, why didn't I put user quotas on /var?)
user quota on var sounds like a good idea.
>
> Assuming you follow that... Should I be able to fix this problem by putting
> the temp-drop in the /var/mail filesystem
Yes, that should be easy, because it is the default.
> and use the -fast-io switch?
and remember (from the same thread) that you can do it on a per user basis.
HTH,
Hugh
