This is the stock QMT setting:
# rpm -qi vpopmail-toaster | grep big
user dir hashing = OFF --disable-users-big-dir
I expect that xaf didn't realize that this is already set. This has
always been the QMT setting afaict.
I don't think xaf is suggesting that this fixes the problem. From what
he's identified, I gather that this behavior is a bug related to the use
of this option though.
I would not recommend enabling this feature. Using the dir_index feature
of the ext3 filesystem is a simpler solution to the problem of
performance degradation with many directory entries.
Thanks to xaf for his research into this problem. We'll attempt to get
this fixed properly in a future vpopmail-toaster (and vqadmin) release,
and submit the fixes upstream.
In the meantime as a work around, I wonder if giving this field a value
of 9999 would coax things to work better, given the fact that this field
is not really used in the QMT configuration. If I understand the
situation, that is.
--
-Eric 'shubes'
On 10/14/2013 06:48 AM, Fabian Santiago wrote:
Hello,
Are you saying that QMT by default uses
"1st QMT build vpopmail with disable-users-big-dir" (and that this
contributes to the cause of the problem)
or are you saying that re-building the vpopmail package with this option
will solve the problem? Thanks. I have seen this happen myself numerous
times with my QMT server.
---
Fabian S.
862-432-2373
On 2013-10-12 09:43, xaf wrote:
|--> LHTek, le 11/10/2013 20:56, a dit :
When I add a domain I've noticed that the VQADMIN "View Domain"
screen is blank. Every other aspect of VQADMIN works as does QMAIL.
After searching for an answer I found that the cur_user column in the
vpopmail/dir_control table needed to be reset. Of the domains that
showed a blank screen in VQADMIN, The content of that particular
field is something like "21441236575" - a very strange number. Upon
resetting it to 0 everything works again.
Although this is more of a encumbrance than real issue, I'm curious
what might be causing this. Has anyone else seen this occur? I would
think that cur_users should be the actual count of the number of
users. I suppose I could write an SQL script to look up each domains
user count and update with real numbers. I'm hoping this isn't an
indication of a larger issue that I'm not aware of.
I'll try to explain, but french native, sorry
1st
QMT build vpopmail with disable-users-big-dir
2nd
when disable-users-big-dir is on
the function which increase cur_users in dir_control is not called
but the function which decrease yes
3rd
vqadmin or its cgi was built with 32bits binary integer instead of
signed integer
which maximum value is 999999999
mod_domain will throw an error when cur_users is > to this value
this error is not catched therefore view_domain is empty
4th
the decrease function simply do a -- to cur_users without controlling
its value
as increase function wasnot called, this value is 0
but 0 -1 makes an overflow and it is system maximum value which is
returned
4294967295 for a 32bits os
1844674407370955161 for a 64bits os
5th
cur_users field is a signed integer
therefore mysql reduces these huge values to its maximum or 2147483647
if you have less than 80000/160000 users
the less effort solution is to change cur_users type from signed
integer to signed/unsigned medium integer
their maximum values |8388607/|||16777215| won't exceed cgi or vqadmin
maximum value
that's all folks
xaf
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
