* Simone Felici <[EMAIL PROTECTED]> wrote: > I know, there is enough written on the net and on the mailinglist too, but > have found only old results, maybe the meanwhile something is different, > also I would ask you... > Which filesystem do you use on your mailserver? > I'm going to migrate a mailserver with EXT3 (and qmail) to a new postfix > mailserver (virtual domains on mysql, ...). > I would create the system on EXT3 (RHES) and the following partitions on > rieserfs: > /var/spool/postfix AND the partition that will contain all mails in MailDir > format.
Postfix works perfectly with it's spool on an ext3 filesystem - or rather, the list of Linux specific issues at http://www.postfix.org/LINUX_README.html does not mention ext3. Given this and the fact that a lot of people are running Postfix with it's spool on an ext3 filesystem suggests that there are no fundamental problems with this setup (well, there is one gotcha: At least on i386, ext3 can only handle 32k inodes per directory). Since some point during development of the 2.4 kernel, ext3 got the ability to use htree hashing for direcotry indexing. I don't know whether the Orlov allocator ever made it to the official kernel, but nevertheless, an ext3 filesystem initialized for storing a lot of small files (inode_ratio = 4096) and htree inidces (-O dir_index) is perfectly capable of dealing with the requirements that mail handling imposes. That said, although I personally never had any issues with ReiserFS, there are really tons of problem reports out there on the net - so I'd never use ReiserFS for any data I care for - though it might be perfectly fine for things like a proxy cache. Besides, I never saw any real performance gains (see below). > At the moment the server has ~100.000 mailboxes and more or less 120.000 > mails stored per day (already filtered trought spam filters from frontend > servers). If directory access times really become an issue, you can always work around that: The configuration parameter virtual_mailbox_maps allows you to store incoming mail in a directory structure of several levels instead of a flat hierarchy. For example: [EMAIL PROTECTED] -> $virtual_mailbox_base/incertum.invalid/cite could also become [EMAIL PROTECTED] -> $virtual_mailbox_base/i/incertum.net/c/cite We cannot give you any advice on a possible way to organize your mail storage without knowing some real data on the number of domains and localparts per domain involved. > Any suggestions? Any test results on both FS to compare with mine I'll > create? Back in 2004, during my time at university, me and some friends performed some quick tests, which you can find at: http://tinyurl.com/6bb3q4 It's in German, but perhaps you can find an online service to translate it - though I seriously doubt it's worth the trouble: Old kernel and we didn't really put that much effort into the tests we performed. There are a number of performance related docs in the Postfix website: http://www.postfix.org/TUNING_README.html http://www.postfix.org/QSHAPE_README.html As a last remark: IMAP servers typically impose a greater I/O load on a system than the MTA itself. There are massive performance differences betweens Cyrus, Courier, uw-imapd and Dovecot, so perhaps you might want to search for a benchmark on those programs. Conclusion: Don't put valuable data on ReiserFS. Don't do premature optimization. You can always change filesystems if your tests show performance gains and you run into performance shortages. Cheers Stefan -- Stefan Förster http://www.incertum.net/ Public Key: 0xBBE2A9E9
