On Tue, 20 Dec 2005, Erik Kangas wrote:
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.
The Apple email client seems to be a particular antisocial with a large
INBOX. We used to be able to tell when one particular Apple user had
arrived, because the mail server would be unusable while their client
connected and scanned for new mail.
I would be curious if Erik Kangas or anyone else has any suggestions on
how to educate senior staff on the "pleasures of small inboxes"
Richard Westlake
School of Crystallography, Birkbeck College, Malet Street, London WC1E 7HX
Tel: 020-7631-6859
----------------------------------------------------------------------
Truth endures but spelling changes -- Anon.
----------------------------------------------------------------------
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
