Selection of most fitting partition/backend upon account creation
Sébastien Michel
sebastien.michel at atosorigin.com
Fri Dec 17 07:50:49 EST 2010
>> fill their mailbox, we would need to retrieve the quota usage of all
> >> those mailboxes. Unfortunately we still have legacy quota db (that is:
> >> one file per mailbox) on most platforms ... and migrating to other db
> >> formats is not always possible since some clients are very picky about
> >> the actions we do on 'their' platform ;)
> >
> > Tell you the truth, I like "legacy" quota DB. It reduces database
> > contention for quota updates. That said, it would be pretty trivial to
> > perform an in-place upgrade of quota data if we wanted to build something
> > good enough.
> We use logical quota for that. It is not RFC compliant (give a string to
> SETQUOTA command) but very useful. The real quota is defined at one place in
> imapd.conf. We can provide the patch if anybody is interested.
>
> >> Considering some backends do host hundreds of thousands of mailboxes,
> >> determining the quota usage of all users would be quite time consuming
> >> for us :)
> >
> > Well, yeah - it's a bit of IO. I don't know what sort of disk you have
> > those files on - we've got either SSD or fast RAID1 drives for our meta
> > partitions, so it's not too expensive to read a hundred thousand
> mailboxes
> > (on the order of a few minutes).
> The choice was made to use NAS storage with lots of disks. Each NAS can
> host 1 to 2 millions mailboxes with some Cyrus above.
>
> > Too expensive to be run PER-MAILBOX. But running it once every 4 hours
> or
> > something to update a stats DB wouldn't be out of the question.
> Yeah. Crawling is our way to get mailboxes figures
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20101217/b426aa1d/attachment.html
More information about the Cyrus-devel
mailing list