On Wed, Jun 29, 2005 at 02:05:23PM +0100, Tony Finch wrote: > On Wed, 29 Jun 2005, Michael Haardt wrote: > > > > A better queue implementation would help a great deal. Possibly by > > using a special purpose filesystem, or by Exim working on a raw device > > or preallocated files. > > That would significantly complicate the code with little advangate, and it > would make programs like exipick and MailScanner impossible.
The code will certainly get more complicated, but given an API, additional programs would be possible. My main problem are disk transfers, not bandwidth. The fsync() calls increase the amount of transfers, because they write data each time it is modified, instead of allowing modifications to be combined and then written. Try to remove the fsync() calls on a busy server and it will fly, but that's not the solution. It just demonstrates the bottleneck, although sometimes I wish I had a global configuration setting for that to clear up a temporary problem. So, what happens when receiving a mail? Exim creates a new file. That means: A new inode (dirty inode allocation structure), a new directory entry (dirty directory content and dirty directory inode), and of course the file contents (dirty block allocation structure, dirty data blocks). That may translate to four disk write transfers. A preallocated file means: A modified inode (dirty inode) and the file contents (dirt data blocks). That are only two transfers. Probably I forgot something here, but it is just an example to show that things could be faster. Michael -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
