It would be nice if some of you could stop with the personal attacks.
While I agree that assuming that all users only receive 4K emails is not realistic in most environments, neither is assuming a requirement of all of the super-duper triple redundant hot fail-over for a mailstore with no quota enforcing.
On 1/14/2011 11:16 PM, Stan Hoeppner wrote:
But Joe User _will_ notice a difference if this server with the RAID 10 mentioned above is supporting 5000 concurrent users, not just Joe. Responses will lag. With the SSD you can support 10000 concurrent users (assuming the rest of the hardware is up to that task and you have enough RAM) and responses for all of them will be nearly instantaneous. This is the difference SSD makes, and why it's worth the cost in many situations. However, doing so will require an email retention policy that doesn't allow unlimited storage--unless you can afford than much SSD capacity.
One thing we are looking at here (small 50+ userbase) is kind of a 'best of both worlds' setup - using SSD's (haven't decided yet to trust a bare striped set or go with a 4 drive RAID10 - probably the latter so I can sleep at night) for the main OS and a limited amount of storage space per user (maildir) for active/recent email, then use another namespace with a much higher quota - I'm thinking about 10GB per user should do in our environment - for 'slow' storage (cheap mechanical RAID10 setup) - ie, emails that are only accessed on occasion (mdbox).
Then, enforce a smallish per user quota (how much would depend on your particular environment, but I'm thinking something like 250 or maybe 500MB, since our users do get a lot of large attachments in the course of doing business) on their INBOX - & Sent, Drafts and Templates folders too, but that's a question on my list of 'how to do' - how to easily place these 'special' folders on the 'fast' namespace, and all user created folders in the 'slow' namespace. It would be really nice if there were some kind of native way that dovecot could 'assign' the 'special' folders to the same namespace as the INBOX, and all other user created folders to another...
Doing this will also help train users in proper email management - treating their INBOX just like they would a physical INBOX tray on their desk. They wouldn't just let paper pile up there, why do so in their INBOX (because they 'can')? Ie, it should be something they should always strive to keep totally EMPTY. Of course this practically never happens, but the point is, they need to learn to make a decision once they are finished with it, and most importantly, take said action - either delete it, or file it.
--
Best regards,
Charles