On Mon, Sep 26, 2011 at 08:46:34AM -0400, Adam Tauno Williams wrote:
> On Mon, 2011-09-26 at 12:01 +0200, Vittorio Manfredini wrote:
> > I found the trick, was a problem on the working account :
> > LOSTQUOTA: unable to record quota file
> > Fixed and now I have the same behavior on both accounts.
> > I think that there are the following possible scenario for an account :
> > 1) account with quota defined (this is the standard scenario)
> > 2) account with no quota (account where quota is not defined, quiet
> > dangerous storage use could grow rapidly)
> > 3) account with unlimited quota (account where quota it's unlimited,
> > but exists and the admin can check the amount of storage used by the
> > account)
> > For the scenario 1) and 2) there are no problem, but how I can realize
> > the third scenario ?
>
> If there is no quota [your case#] there is no server-side tracking of
> storage; the only solution is to walk the mailbox [and subordinate
> mailboxes], which has numerous issues of its own.
The whole point is that quotaroot at "user" level is purely a convention
and not enshrined anywhere - so short of keeping sums of all subordinate
mailboxes at every level (the top would be very locky) there's no
sensible place to keep it other than quota_mailbox_used on each mailbox.
> I agree it would be very useful if the server kept capacity information
> on-hand regardless of quota settings. I'd like to see a "real size" and
> "allocated size" values. For example I'd like to know the size
> including delayed-expunge messages.
Hmm... interesting. That would actually not be too hard to do.
> On the other hand, putting on my sys-admin hat, is #2 a real situation?
> If madly growing allocation is a potential issue it would see the
> solution is a very large quota and to track some threshold of that
> quota.
Yeah, exactly. That's the sane workaround. Give everyone a 100Gb quota
and relax.
Bron ( if you have users over 100Gb I pity you, and them if they're trying
to sync that stuff over IMAP! )
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
