> > I would vote for this and I would use this. In particular, I would
> > imagine a periodic process that
> >
> > * See if there is contiguous space available to defragmentation on the
> > system (and how big?)
> > * finds "large" folders (especially INBOXES)
> > * Sees if they are fragmented
> > * If they are "sufficiently fragmented", defragment
> >
> > This would help performance somewhat for people to keep large inboxes --
> > until they can be taught the pleasures of small inboxes.
>
> I would be interest in what people consider being a reasonable maximum
> INBOX size and if there is any online resources covering the problems
> caused by large INBOX.
>
> Most of the accounts on our email serve have an INBOX smaller then
> 150Mbyte, the rest are smaller then 500Mbyte, which is an improvement as
> we did have, files larger then 1Gbyte.
[stuff deleted]
We limit the inbox to about 15MB (+/- 5MB depending on who you are) via
the lock+move+unlock+inform method. This may sound draconian but keeps
inbox sizes down, the user knows how to get the moved mail, and all are
generally happy.
We have four two-node Sun V400 clusters typically with 1K users on each
cluster.
--
scott hollatz net [EMAIL PROTECTED]
information technology systems and services tel +1 218 726 8851
university of minnesota duluth mn usa fax +1 218 726 7674
--
"gabba gabba hey" - the ramones
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
