Dave Goodrich wrote:
<snip>Michael Bowe wrote:
----- Original Message ----- From: "Dave Goodrich" <[EMAIL PROTECTED]>
Mark Richardson wrote:
<snip>
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
I looked Friday into the largest domain (most users) and found the following,Ok, that worked somewhat. We are now creating the users within the proper directory. Hmm, how does vpopmail know when to use a new dir?
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 my thought on the value of level_indexX is correct, might level_modX tell vpopmail when to create the next dir in line?
I will fill that dir "u" with new users and see if a dir "v" is created. That should also change level_index0 to "57", I believe.
DAve
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.
