At 11:52 AM -0400 4/7/06, 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
This is the classic problem with using filesystem quotas to enforce
mailbox size limits. It's been discussed on the lists for years,
because there is no really good solution. Personally, I think it is
better to enforce mailbox size limits using another mechanism, such
as scripts that run periodically and can use whatever enforcement
methods are desired, such as sending warning mail to the user,
disabling the account from receiving mail, etc.
Should I be able to fix this problem by putting
the temp-drop in the /var/mail filesystem and use the -fast-io switch?
No, because fast-update only uses rename() instead of copying at the
end of the session. And it can only do that if the no new mail
arrived during the session.
By the way, the option is 'fast-update' not 'fast-io' -- I used the
wrong name in an earlier email. Sorry for misleading you.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
For best results, be sure to double clutch when you paradigm shift.
