Re: [exim] maildirsize exim vs courier

トップ ページ
このメッセージを削除
このメッセージに返信
著者: W B Hacker
日付:  
To: exim users
題目: Re: [exim] maildirsize exim vs courier
Heiko Schlittermann wrote:
> Hello Bill,
>
> thank you for thinking and responding.
> But …
>
> W B Hacker<wbh@???> (Di 01 Feb 2011 18:58:50 CET):
>> Heiko Schlittermann wrote:
>>> Hello,
>>>
>>> ---
>>>
>>> abstract: Exim counts<T> tagged (marked for deletion) files
>>> when recalculatint the maildir quota. How to skip these files?
>>>
>>> ----
>>
>> du -c /path/to/Maildir/cur/*.?T?
>>
>> .. perhaps coupled with a bit of regex, might be a starting point...
>
> - I do *not* want to count these files. (or at least I'd like to have
>    a runtime option to skip these files)


Calc method aside, doesn't that in effect 'reward' those who cannot be bothered
to expunge, and/or who use their .Trash as a scratch storage area?

I've had IMAP users who tried that with *years* worth of messages...

Seems better to INCLUDE those files in the count and penalize the sloppy, not
exclude and let tem continue poor practice at the expense of the overall user
community... and your hardware and admin expense as well..

>
> - Using du(1) isn't an option.
>      - because exim does the recalculation on its own when the magical
>        5120 bytes size limit of maildirsize is reached


I hear you - but at the end of the day there is a ton of machine code and I/O to
be executed by *something* any way you cut it. 'Magical' just means *we* don't
see the auto-fornication motion..

>      - because we're talking about 120k mailboxes on some NFS share
>        (netapp)

>


120,000 Maildir's at what average population? ten files each? fifty each? A
hundred?

I would at least use du to get those stats for planning....

> - Using du(1) is not necessary at all, because the files already
>    have their size coded in the S=… tag of the file name.

>


As soon as there is more than one file involved, parsing info from the file
*names* rather than the fs doesn't seem to me to be an improvement when you have
to extract, manipulate, calculate for 'many'.


But .. methodology aside for a moment...

Do you have any chance of dropping - or at least loosening - quotas in favor of
allocating the account storage across multiple, separate 'chunks'?

- more storage is usually cheaper than more admin labor/stress

- separating the 120,000 Maildir into subsets should produce less drama
if/as/when some part goes offline - even if just for maintenance.

> Greetings from Dresden/Germany


Kung Hei Fat Choy from Hong Kong,

Bill