On Wed, 30 Jan 2008, Ed W wrote:
I misunderstood the cause of the slowness then, if it is really true that updating the index is not an important factor. I don't remember seeing profiling, but since I don't have any myself I'll take your word for it.
It always frustrates me to see people speculate on stuff instead of getting their stop watch out and trying it
Just get a small shell script to run
touch ${rand_file}35,000 times and time it. Then drop into your shell and do rm -rf on the folder (for bonus marks you could purge the disk cache before doing this). This gives you a benchmark on your hardware separately to what dovecot offers. Take that number and lets work from there... Shouldn't take too long to do something like this?
Since the problem is supposedly file-system specific, you're assuming Asheesh uses the XFS file system. And seeing as how he's not the one with the original problem, it's also assuming he cares enough to run a test like that. Since it was put forth already in the thread that the file system is the problem, there's not much incentive to test that hypothesis if it involves non-trivial work.
I know I've definitely wasted a lot of time testing out some of the various problems that have come up on this list by setting up weird dovecot installations. But, not everyone wants to do that for every single case.
Plus, in this case, you can just google: xfs delete.
The first result[1] points out the importance of tuning, but the third[2] shows exactly what was said on the list: XFS shows very poor delete performance on directories full of small files. (Deleting a directory with ~8000 small files, times in seconds: JFS 3, reiser 1, XFS 30, ext3 2)
[1] http://everything2.com/index.pl?node_id=1479435 [2] http://sidux.com/PNphpBB2-viewtopic-t-5275.html
Best, Ben
P.S. Rereading this it sounds more confrontational than I'd meant to be. No offense intended - just a general: running your own benchmarks isn't always worthwhile or necessary, especially when it's not your problem.