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.
>
> Also, just switching the position of the microseconds and epoch seconds
> in the new long queue-id is perhaps not quite enough, the first character
> of the new microseconds has only 8 possible values (0-7), previously
> the range was 16 values (more effective hashing).
>
> Use of base 32 encoding, would give a much better result, since 32^4 is
> 10^20 or just over a million, so the microseconds can be encoded just
> as efficiently in base 32 as in base 51, but the distribution of the
> first character is much more uniform (32 possible values).
>
> So my proposed update for the long queue id is:
>
> - 4 octets of base 32 encoded tv_usec
> - 6+ octets of base 51 encoded tv_sec epoch time
> - one non base 51 octet separator
> - inode number in base 52.
Better: use reverse microseconds + reverse seconds (i.e. LSB
first, base 52 encoded). Then we can have 52 possible values per
character for queue hashing. With two levels of hashing we get
10x fewer files per directory compared to old queue file names.
We'll also need some postcat command option to decode such
information for forensic/trouble shooting purposes.
Wietse
