> > >> I don't actually know what sort of problems I'm referring to, hence the >> question. The big problem I can imagine would be opendir() and >> readdir() with a huge number of files in a directory, but the cyrus code >> doesn't appear to do that in a lot of places that would matter to a user >> (deleting an entire folder, delete sieve scripts, etc) in the course of >> normal operations. > > The number of files in a directory certainly seems to be the performance > factor for us. We don't enforce quotas, but our largest mailboxes are > only about 15Gb. Deleting large folders (~100000 messages) does take > some time. The only event that has troubled other users of the system > was one user who had added 7.2 million messages to their trash folder, > and then emptied their trash. It took the better part of a day to > finish, and impacted both read and write performance for other users > (nexsan providing storage over fibre, xfs on top) but the service kept Speaking of XFS it was quite slow in deleting large number of small files some years ago. If that's still true it may be what you saw. Since delayed delete has been enabled those issues have not be seen over here. Simon ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
