Dave Goodrich wrote:
Michael Bowe wrote:
----- Original Message ----- From: "Dave Goodrich" <[EMAIL PROTECTED]>
Mark Richardson wrote:
<snip>
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.
Thanks,
DAve
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
http://www.mail-archive.com/vchkpw@inter7.com/msg18604.html
This is where I got the idea, "change something and see what happens"
http://www.mail-archive.com/vchkpw@inter7.com/msg05262.html
Best explanation yet, but it still doesn't explain what level_modX does,
or what level_indexX does.
http://www.mail-archive.com/vchkpw@inter7.com/msg04465.html
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.
http://www.mail-archive.com/vchkpw@inter7.com/msg16037.html
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.
Thanks,
DAve
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?
Michael.
We figured that was an error, replaced the value and everything
continued properly.
