Victor Duchovni:
> On Sun, Mar 20, 2011 at 03:57:45PM -0400, Wietse Venema wrote:
>
> > Below is the manpage entry for long queue ID support. Let me know
> > if there's anything missing.
>
> With the first few characters of the new long queue-id encoding the
> epoch-seconds time and not the micro-seconds time, it seems to me that
> the current scheme for "hashing" the "deferred" and "defer" (and perhaps
> other) sub-queues needs adjustment.
That is a very good point. Rather than overhauling the name scheme
or using three different encodings for seconds, microseconds and
inode number, I made a tiny change in the hash_queue_names algorithm.
With long queue file names it now takes the (full time in seconds
+ three least significant characters from time in microseconds),
then uses the last characters for hashing, so that:
3Ptdbd0p9qz1PFjk becomes q/9/3Ptdbd0p9qz1PFjk
(here, 3Ptdbd = time in seconds, p9q = three LSB from microseconds).
This way we can have meaningful hashing over more than three levels,
with fewer files per directory because we have base 52 instead of
base 16.
I initially used the last characters from the whole file name (the
inode number portion) but I was concerned that some systems may
have unexpected structure in their inode numbers causing the hashing
to become uneven (perhaps when some file system uses fake inode
numbers that are really cookies of some kind). It also would not
look pretty with dedicated queue file systems where inode numbers
can be really small.
Wietse
