Hi, I'm about to start a conversion project of our University email system based on mbox folders to Courier IMAP maildir. There are about 50K users using about 250 GB of space on F840 cluster; Netapp version 6.2.2. We have been also told that as of this year each student will keep their account for life, therefore this number will keep on growing.
Wow! This is a very interesting decision. Did the powers that be consider policy problems such as email abuse? What happens if an alumnus starts using your email system to send spam? Do you delete their email account? Can they ever get it back? At least you have some leverage over enrolled students when enforcing your policies. You don't have any leverage at all over alumni, except to disable the account. Will alumni need to sign an agreement to abide by your policies?
Also, what happens if the alumni adversely affect email performance for the enrolled students, faculty, and staff? Is there a commitment to fund necessary upgrades? Is it fair to ask enrolled students to partially fund the email of alumni? If some of your funding comes from the government, is it even legal to provide this service to alumni? Is it a misuse of funds? (That is an issue here at the Univ. of Virginia.)
What sort of support are alumni entitle to? Can they call your help desk? How will that impact service for everyone else?
How are you going to handle email that just piles up when alumni never log in to read it any more? Most of our students routinely receive spam, and many are on active mailing lists. If we didn't delete their email accounts when they graduate, this stuff would just keep coming in forever.
I don't see how treating alumni and enrolled students the same can possibly be fair to the enrolled students, especially as the number of alumni keeps growing. In four years the number of alumni accounts on your email system will roughly equal the number of enrolled students, and after that, the alumni will be a growing majority.
Forgive me if I misinterpreted what you are planning to do.
I'm very concern about the number of inodes/files/volume and the filer performance.
From all the information I could find some of you said that you get about o one inode for every 32 K o can be increased to as much as 1 inode for every 4 K (maxfiles)
There was also some discussion that when you do this, the internal WAFL tables become so huge that it will impact performance.
I don't think the performance issue is a show stopper. If you had the choice of storing 250GB as 1 million files or 250GB as 100 files, which do you think requires less space and performance overhead? But you don't have that choice. Given that you need a large number of files, netapp will handle that situation at least as well, if not better, than anything else out there.
Bear in mind that a file under 64 bytes long consumes zero data blocks, but still consumes one inode. That is because up to 64 bytes of data can be stored in the inode itself. So even if you have one inode for every 4k data block, you could still theoretically run out of inodes, although it isn't likely. You can verify that short files use no blocks with the "du -k" command on a NFS client.
32 million / 50 K users gives me only about 650 files; this is clearly not enough.
Will someone having gone thru this type of a conversion give me some pointers of what to do and what not to do ???
Thanks, George
George Kahler e-mail: george@yorku.ca Sr. Systems Administrator humans: (416) 736-2100 x.22699 Computing and Network Services machines: (416) 736-5830 Ontario, Canada, M3J-1P3
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support