Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Spiros Ioannou <[email protected]>
| Newsgroups | gmane.mail.qpopper |
|---|---|
| Message-ID | <[email protected]> |
I have a patch for this, see here: http://www.mail-archive.com/[email protected]/msg05281.html and here: http://image.ntua.gr/~sivann/test/popper-ntua.tar.gz The patch keeps the spool lock active while the mail is in the temp. New mail waits for the spool to unlock. I can't understand why this is not default/option. -S 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. > > 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] >