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.
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". * 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 * 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?) Assuming you follow that... Should I be able to fix this problem by putting the temp-drop in the /var/mail filesystem and use the -fast-io switch? > -----Original Message----- > From: Randall Gellens [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 09, 2006 3:13 PM > To: Hugh Sasse; Gregory Hicks > Cc: [email protected] > Subject: Re: Large spool mboxes => slow? [snip] > You might also want to think about using the fast-io option, which > renames the temp-drop to the spool instead of copying it. This only > works if the temp drop and spool are on the same filesystem. [snip]
