[SOLVED] Mail Store File System Size?

[deckard]

At the moment, I'm assuming that since Zimbra installs into /opt, that I need to make sure that /opt is large enough for my (maximum number of users * per-user quota). Currently, I'm looking at 200 megs per user * 2000 users. To be safe, I've created a 500 gig logical volume (Redhat Enterprise Linux 5 as a Xen "guest" on a CentOS 5 "host") for /opt. But... when I was trying to format this file system with ext3, it took a good 40 minutes. (The file system is on a SAN, so I wouldn't expect the performance to be that slow. I did a little reading on Xen and found that disk I/O is a little better when the file systems aren't too large (over 100 gigs let's say). So is it possible for Zimbra to partition it's mail store across multiple file systems? If so, I think that could solve my problem...

[martin.marcher]

Originally Posted by deckard

At the moment, I'm assuming that since Zimbra installs into /opt, that I need to make sure that /opt is large enough for my (maximum number of users * per-user quota). Currently, I'm looking at 200 megs per user * 2000 users. To be safe, I've created a 500 gig logical volume (Redhat Enterprise Linux 5 as a Xen "guest" on a CentOS 5 "host") for /opt. But... when I was trying to format this file system with ext3, it took a good 40 minutes. (The file system is on a SAN, so I wouldn't expect the performance to be that slow. I did a little reading on Xen and found that disk I/O is a little better when the file systems aren't too large (over 100 gigs let's say). So is it possible for Zimbra to partition it's mail store across multiple file systems? If so, I think that could solve my problem...

That took so long because ext3 assigns a fixed number of inodes. for mailstores I suggest a filesystem assigns inodes dynamically personally i prefer xfs but i heard that jfs also seems to be quite usable. Also you don't have to tweak around with ext3 with the various options (there's a special "class" you can use with ext3 to create a mailspool that let's you have more files in a filesystem and that is optimized for a large number of small files (i think it's mentioned in tune2fs - something like that)

xfs also has the pro of being expandable while online. In fact it has to be mounted to be expandable.

[deckard]

Originally Posted by martin.marcher

That took so long because ext3 assigns a fixed number of inodes. for mailstores I suggest a filesystem assigns inodes dynamically personally i prefer xfs...

In all of my systems at home I avoid ext3, so xfs sounds like a great fit and I've read about it's benefits before. My only concern is that It doesn't appear that Redhat supports it. It's not in their default kernel and I'm not sure that I would get support from them if I compiled my own kernel with xfs support. But I'm also new to Redhat Enterprise Linux... Most of my background is Fedora, Gentoo, and CentOS where I can do anything I want without needing to worry about support. My managers want us to use a supported Linux in case I get "hit by a bus" since I'm the only *nix guy here.

[martin.marcher]

Originally Posted by deckard

In all of my systems at home I avoid ext3, so xfs sounds like a great fit and I've read about it's benefits before. My only concern is that It doesn't appear that Redhat supports it.

If you're bound to support (which i suspect if you use RHEL) look into tune2fs there are a couple of howtos and best practices what to set on ext3 for mailstores.

The cyrus mailstore is very much Maildir like (in terms of file and storage demand) so a maildir+ext3 reference should get you started.

Oh and personally if you pay for the support and have a kernel with only ext3 i'd either

a) drop payments for the support or
b) make sure that ext3 only is just a default and you won't loose any support when using an xfs enabled kernel...