> Ext4, I never tried. Nor reiser3. I may have to, we will build a brand > new > Cyrus spool (small, just 5K users) next month, and the XFS unlink > [lack of] performance worries me. >From what I can tell, all filesystems seem to have relatively poor unlink performance and unlinks often cause excessive contention and IO for what you think they should be doing. And it's not just filesystems. SQL deletes in MySQL InnoDB are way slower than you'd expect as well. Maybe deletes in general are just not as optimised a path, or there's something tricky about making atomic deletes work, I admit I've never really looked into it. Anyway, that's part of the reason we sponsored Ken to create the "delayed expunge" mode code for cyrus, which allows us to delay unlinks to the weekends when IO load due to other things is the lowest. --- Added support for "delayed" expunge, in which messages are removed from the mailbox index at the time of the EXPUNGE (hiding them from the client), but the message files and cache entries are left behind, to be purged at a later time by <tt>cyr_expire</tt>. This reduces the amount of I/O that takes place at the time of EXPUNGE and should result in greater responsiveness for the client, especially when expunging a large number of messages. The new <tt>expunge_mode</tt> option in <tt>imapd.conf</tt> controls whether expunges are "immediate" or "delayed". <i>Development sponsored by FastMail</i>. --- Rob ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html