On Fri, 2009-01-09 at 08:57 -0600, Matt Brookings wrote:
This would not work because users can be deleted out of the hash tree
anywhere. It appears your patch assumes a FILO ordering of user additions
and deletions.
I have not been able to explain properly. It would be FIFO.
If the hashes,
On Monday 12 January 2009 07:48:17 am ISP Lists wrote:
Can someone please provide a brief discussion as to when a vpopmail hashed
folder tree becomes big enough to warrant backfilling? Or, is big
just one concern amongst others such as: rate of deletes and adds,
filesystem choice...
I'm not
Manvendra Bhangui wrote:
Now let say I delete a user who has a directory
in /var/vpopmail/domains/1
The backfill code will put the entry '1' in the first line in the file
dir_control_free.
So after deleting 3 users, the file dir_control_free will have 3 lines
1
2
2
Each time the
ISP Lists wrote:
Can someone please provide a brief discussion as to when a vpopmail hashed
folder tree becomes big enough to warrant backfilling? Or, is big
just one concern amongst others such as: rate of deletes and adds,
filesystem choice...
I'm not quite picking up why the backfill is
Joshua Megerman wrote:
One last note - the idea of maintaining a list of backfill slots in a text
file is a pretty good one, but it still doesn't address the issue of not
properly calculating the number of users in a directory...
What are you referring to when you say it doesn't properly
Matt Brookings wrote:
Remember that this feature does not yet exist, and that there are probably
many systems with backfilling needs that go back years. Potentially this
patch could hit a system with four levels of hashing simply because there's
been a lot of additions and deletions. If the
