Dave Goodrich wrote:
Michael Bowe wrote:

----- Original Message ----- From: "Dave Goodrich" <[EMAIL PROTECTED]>

Mark Richardson wrote:


OK, I'm going to reopen this thread as I have taken a break from the issue to deal with other things. Looking again at my user distribution I see the issue has not changed at all. At my last thread update I was adding users to the "u" directory, this has not changed. My current distribution is like so,

a ->       53
b ->       19
c ->       50
d ->       74
e ->       11
f ->       13
g ->       13
h ->      120
i ->       34
j ->       34
k ->       33
l ->       30
m ->       48
n ->       34
o ->       66
p ->       29
q ->       37
r ->       55
s ->       47
t ->       54
u ->     1034
0 ->       62
1 ->       69
2 ->       76
3 ->       72
4 ->       66
5 ->       70
6 ->       69
7 ->       60
8 ->       72
9 ->       66

Yea, "u" is still getting users added.

My dir control table looks like so,

| domain  tls.net
| cur_users 3822
| level_cur 1
| level_max 3
| level_start0 0
| level_start1 0
| level_start2 0
| level_end0 61
| level_end1 61
| level_end2 61
| level_mod0 0
| level_mod1 2
| level_mod2 4
| level_index0 56
| level_index1 8
| level_index2 0
| the_dir u

Only the curr_users field and level_index1 field have changed (see older posting below, level_index1 was 0 now is 8).

I am running vpopmail-5.4.6 on this machine. I have 5.4.10 with several new changes on my dev server, but I would like to solve this problem first, unless someone can tell me the problem is solved in 5.4.10?

So, has anyone seen/fixed this issue? Anyone have a good explanation of just how the dir_control system works? I am about to start deciphering it again and trying to find a solution.



Note: Read the older message below, but as a refresher, I had no issues when using cdb files. Once I migrated to MySQL backend, dir hashing stopped, though it seems vpopmail knows about the dir_control table as it it properly updating the cur_users field.

I have looked at the dir hashing code before in an effort to try and
understand it, but not being an expert C programmer, it makes my head spin

In the mailing list archives there are many accounts of the type of problem
you describe

Do you mean
This is where I got the idea, "change something and see what happens"

Best explanation yet, but it still doesn't explain what level_modX does, or what level_indexX does.

This is the message that made me think getting an answer wouldn't be so hard.

This is the other user with the same problem I am experiencing, no solution either.

I looked Friday into the largest domain (most users) and found the following,
4500+ users
user hash dir 0-9 used
user hash dir A-Z used
user hash dir a-z, currently in "u"

I believe this means that I have hashed up to "1" level and I am currently in "u". The source code says I should have the ability to hash into 0-9, A-Z, a-z, which gives me 61 levels (not 62, start counting at 0) since the level_endX fields all read "61" this makes since to me.

So I believe..... I should have the following values for this domain.
cur_users = 4555
level_cur = 1 # how deep have I hashed already
level_max = 3 # how many levels to hash
level_start0 = 0 # where to start hashing
level_start1 = 0
level_start2 = 0
level_end0 = 61 # how many total dirs to have per level
level_end1 = 61
level_end2 = 61
level_mod0 = ? # no idea what this does, currently reads 0
level_mod1 = ? # currently reads 2
level_mod2 = ? # currently reads 4
level_index0 = 56 # how deep have we hashed within the first level
level_index1 = 0
level_index2 = 0
the_dir = u # the dir we are currently adding users to

If this jogs anyones memory, that would be great. I am going to plug these numbers in and see what happens. If anyone out there with more than 5000 users in a domain could send me the contents of their dir_control table, it would be very very helpful.



I believe that the large number in the cur_users field comes about because that field is typically 32bit (ie max value 4294967295) and perhaps if the value is 0 and gets 1 subtracted from it incorrectly during the conversion,
you end up with numbers wrapping and being displayed in that range). Or
maybe there is a part of the code that mixes signed and unsigned integers
resulting in that bug?


We figured that was an error, replaced the value and everything continued properly.

Reply via email to