>> 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 >
