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
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
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
On Mon, Mar 21, 2011 at 07:15:44AM -0400, Wietse Venema wrote:
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.
On Mon, Mar 21, 2011 at 01:29:15PM -0400, Wietse Venema wrote:
I thought of that. This is not a problem with today's default
configuration where the high-traffic queues (i.e. incoming, active)
are not hashed.
Do you expect that there will be configurations that do hash their
high-traffic
Victor Duchovni:
Also, with a little-endian base 52 queue-id, and hash depth of 2,
we have 2704 directories to search, while big-endian 32 x 32 takes us
to 977 directories as compared to 245 directories for big-endian base 16.
Base 52 requires fewer levels of hashing than smaller
Wietse Venema:
I could just forget about lexicographical hashing and simply hash
the hexadecimal representation of the microseconds (extracted from
the queue file name and converted from base 52). With this there
would be no change in file distribution compared to Postfix 2.8.
Below is the manpage entry for long queue ID support. Let me know
if there's anything missing.
This code is part of this weekend's snapshot (*). Several iterations
have been running on my systems through the past week.
Wietse
(*) As of Postfix 2.9, snapshot releases happen on weekends.
