Scott Edwards wrote:
At the onset, I decided to just keep all email accounts (in Maildir format) below /var/mail/user@host/. This is working ok for now, but I'm sure after I approach a few hundred accounts, it will become less desirable. The billing management system uses unique numerical id's i can use. The directory location for each account is stored in a virtual email table in the database accessible by the smtp, pop3, imap and webmail services. (postfix, courier, sqwebmail). A few trivial modifications to the provisioning script I have is all that should be necessary to put something new in place. (optionally moving existing accounts to their new home). There are only a few accounts handled via local mail, everything else is virtual mail. Using numerical account id's (or any suggestion you can offer), what are the most scalable options for this scenario? There's only a few hundred email accounts right now, but what options should i consider to keep the directory sane when I approach hundreds of thousands of accounts? I am using ext3fs under a 2.6 Linux kernel, but may consider some type of NFS further down the road. I look forward to any worthwhile input you may provide.
I'm sure there are better methods, but I can suggest a simple one that I've used successfuly in the past.
Create subdirectories based on the first and/or second letter/number of the username or id. If you expect a few thousand users, you can just use the first letter, eg
/var/mail/FIRSTLETTER/user@host_or_id If you expect many thousands, you can use the first, eg /var/mail/FIRSTLETTER/SECONDLETTER/user@host_or_idThis will make sure you don't have too many inodes in one directory. Also, you can make the different filesystems pretty easily if necessary. I had to do this once many years ago due to filesystem size limits. We were using a SAN and veritas filesystem so we could easily grow and/or break off pieces to create new file systems. For example, /var/mail could be your 'primary' filesystem and can you create 'secondary' filesystems for whatever reason; such as /var/mail/a, /var/mail/b, etc.
In short, there are probably better ways, but this is pretty simple. :) thanks, M -- Michael Sprague | mfs@saneinc.net System and Network Engineering (SaNE), Inc http://www.saneinc.net | use STD::disclaimer; -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.3/209 - Release Date: 12/21/2005