Some comments in addition to the good stuff that's already here. I think I may be repeating what others have said as well to a certain extent.
I'm slightly surprised that you have so many files in ~/temp, but they can be cleaned up. A safe way to clean things up is
This removes files over a week old.
You're not going to get much performance difference between ext2 and ext3. If these files are genuine (that is, not as a result of something being broken) then you can enable directory hashing. I just did this:
Code: Select all
tune2fs -O dir_index /dev/vg/build
umount /dev/vg/build
e2fsck -fD /dev/vg/build
mount /dev/vg/build(/dev/vg/build is where I do my builds, I thought I might try it to see if it makes builds faster.) You'll notice that you have to take the file system off-line to build the indexes, but it doesn't seem to take long on my 3G build partition.
There are other options. You want ~/tmp and ~/temp to be as fast as possible but you don't care what happens to them if the machine crashes (or at least you shouldn't). Create fresh file systems for ~/tmp and ~/temp and mount them with options to make them "fast and dangerous". Good ones are noatime, nodiratime, data=writeback -- see the mount(8) and Google for details. Mount these file systems as ~/tmp and ~/temp (usually /var/opt/scalix/tmp and /var/opt/scalix/temp) -- please don't use symlinks and have them mounted somewhere else, it'll only slow things down.
It's best to re-create fast and dangerous partitions like these on reboot. You'll need to set the dir_index option when you create the file system, of course. If you have a ramdisk then you can use that for the journal and that will also speed things up -- it might make sense to use "data=journal" in this case so that writes to the disk are buffered through the journal; I don't know if this would be faster or not.
If you have more memory than is good for you, you can try using tmpfs for these file systems, but bear in mind that, of course, they'll be competing for memory with running processes. I've used tmpfs for /tmp on Solaris and it's blindingly fast and falls back to swap when real memory runs short; I've not tried it at all on Linux (but perhaps I should). It could be that this is far and away the fastest way to get a file system, but, equally, since I/O from the swap partition(s) isn't optimised for a file system it could be rather slow unless you have loads of real memory.
If you're using an array for disks, then configure ~/tmp and ~/temp to be on striped but not mirrored volumes -- you'll get the most throughput that way but, of course, you're vulnerable to losing that valuable throw away data :-) What we're after here is speed, not safey. There's a theme developing here. A single disk for any significant number of users is going to glow red hot and it'll be a bottle neck.
Dave mentioned UAL_SINGLE_TEMP_DIR and that's especially useful when you've arranged to have fast file systems for tmp and temp. Several people have mentioned ownership and permissions of those directories -- get it right or Scalix won't start.
I'm still slightly surprised that there are so many files in ~/temp though -- I'd love to know what they are.
I'm not a bit surprised about the speed of an IMAP search. You'll be in for a very pleasant surprise in the next release though.
jch
