Scalix Forums

I have been reading this article on KernelTrap, describing a debate amongst the kernel devs regarding atime. http://kerneltrap.org/node/14148

This made me wonder, are there any dependencies in Scalix that requires atime to be correct? I know Scalix is very much IO-bound (especially reads), so I think this could have an impact on large installations.

I am always loath to move away from the distro defaults (in the RH case keeping atime enabled), but if there's no risk of things not working correctly I can easily enable this on some installations.

I was reading that article too. On our file servers atime has now been removed, but I'm leaving it on for the mail system ... I'm mounting the entire /var directory on it's own partition, not sure if it's a good idea to mess with atime there. So if anyone has any info it would be appreciated!

I have a test box that i use for upgrades, that is a duplicate of my scalix install. I'm going to try remounting /var/opt with no atime, and see what happens. My prod machine is rather I/O bound, so i'm hoping this will help alleviate some of that. Should be able to test this sometime this weekend.

I've just searched the code for uses of atime in the code. There's one place where omscan carefully preserves it (I think so that orphans don't appear to be accessed unnecessarily) but that's it.

The only thing that might cause problems with access time is scripts that are looking for files to delete in ~/tmp and ~/temp. I did wonder if omscan's normal temporary file clean up was using the atime for that, but it appears not. Nothing in our server sources uses find's -atime though, at least nothing that grep can find.

I read the kerneltrap article last night. The "relatime" patch looks interesting, but what I found much more interesting was the discussion about fsync(2). We like fsync, we like it a lot, we call it all over the place Actually, that's only half true. We do use fsync(2) a lot, because we commit changes to the disk a lot. It would be nice to be able to rely on the ext3 journal to do that for us, but we can't. It appears that fsync(2), however, is a little inefficient because it flushes all pending changes for the file system. This might be hurting performance quite a bit -- it's hard to be definitive about it because most changes to the message store are committed with fsync(2).

What the behaviour of fsync(2) does really underline though is that you are definitely better off having ~/tmp and ~/temp are separate file systems and you can have the "noatime,nodiratime,data=writeback" options on those file systems because we don't care about the contents after a crash.

It would be nice to hear from someone who has mounted their message store noatime,nodiratime and measured the performance difference.

Meanwhile, on my laptop, I've just done a fresh svn checkout of the source into a noatime,nodiratime file system to see how much difference it makes. I'll let you know in about 20 minutes.

jch

I'm not really surprised: the compilation time was about the same as normal, it would probably improve if I mounted my root file system noatime,nodiratime to avoid writing the atime on all those files in /usr/include.

While the compilation was running I was thinking about how much it would benefit the performance of the mail server. On a reasonably configured server, disk I/O is split pretty evenly between read and write: the number of file system reads compared to file system writes is enormous, but the cache takes care of most of the reads. Most of the writes are very small (there are places where we just write two ior three bytes). The number of file system reads though, does suggest that the number of times that the atime is written is going to make a difference to the overall I/O burden. It may well drop the number of writes by an appreciable amount, especially given the behaviour of fsync(2).

We're not in a position to do comparative performance analysis right now, but I really would love to hear from someone who has tried it, even if to say "seems snappier" or "no discernable change".

Of course, all I've done is grep for uses of the atime, it's possible that I've missed something important, so go carefully.

jch

Hi out there,

any news on this topic?

I did some performance tests on machines with heavy IO (none scalix services) where mounting filesystms with the 'relatime'-option improved the situation significantly.

Thanks & regards
stephan

What's "relatime" (yes, I could google, but I'm lazy right now)?

I know of "noatime" and yes, running Scalix with that mount option used is actually supported as well as "recommended" (although impact doesn't seem to be that large!)

Florian