----- Original Message ----- From: "Dave Goodrich" <[EMAIL PROTECTED]><snip>
Mark Richardson wrote:
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/[EMAIL PROTECTED]/msg18604.html This is where I got the idea, "change something and see what happens"
http://www.mail-archive.com/[EMAIL PROTECTED]/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/[EMAIL PROTECTED]/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/[EMAIL PROTECTED]/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
We figured that was an error, replaced the value and everything continued properly.
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.
