Re: [exim] Small modification for queue runners?

One other thing to consider here is that unix takes *very* long to open a
file in a directory with 500k files (the spool of 244k messages mentioned).
I've seen a full minute to create a file in such a directory (fairly old
machine but not *that* old). (create is slower than *any* other open.)
If the spool is going to get that big one should hash the names into
subdirectories... And if all queue runners are doing this at the same
time, readdir() will get pretty bogged down.

One other approach to speeding this up would be a db file (hash or btree)
parallel to the spool directory (or indexing into it). That should speed up
the randomisation of the queue runners' sending order a lot over a raw
directory if the queue gets very big. OTOH it would be lots of extra
overhead in any of my cases... (my queue never gets over 100-200).

Freebsd has the dirhash option but I don't know if the kernel memory it
uses for that is persistent when the dir gets *that* big. I don't know
what other unices (or similar) do here. Mac HFS would be OK (btree dirs;
worse for sequential reads but quick for opens) but I don't know if OS-X
uses those or not.

-- Pete