Wietse Venema:
> 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.
In fact, the existing base 52/51 ID is optimal when we use the last
characters (the LSB end) for directory hashing. This is a near-trivial
code change, and it spreads the queue evenly over 52 subdirectories.
> We'll also need some postcat command option to decode such
> information for forensic/trouble shooting purposes.
Meaning, given a queue ID of 3PtcSh3sXLzHQDd, present it as date
+ microseconds + inode number if is a well-formed long Postfix
queue ID (3PtcSh = Mar 21 08:50:12 2011).
Wietse
