On Tuesday 01 February 2005 7:32 pm, Michael Bowe wrote: > ----- Original Message ----- > From: "Tom Collins" <[EMAIL PROTECTED]> > > > I've been thinking about modifying vpopmail to use directory names like > > @a, @b, @c, etc. instead of a, b, c so that we could allow > > one-character user directories in all cases. I don't know how we'd > > make that work with existing directory structures though. Another > > solution would be to hash all usernames, so there weren't any users in > > the top directory. I guess we'd still run some risks of qmailadmin > > creating a mailing list or autoresponder with the same directory name > > and then later deleting it. > > I have often wished the directory hashing worked in a more > simple/logical fashion
We choose what looked to be the most efficent method of storing the directories and attempted to automate as much as possible. > > Is the complexity of the current system really required? I think so. So did all the developers who worked on the code. Our testing showed that it was required. > It is so complex > that none of the developers even appear to understand how it works! I do. > The documentation states that vpopmail uses a self balancing tree that is > able to support up to 23 million domains, each with up to 23 million > users. However I am a bit doubtful about the "self balancing" part. > For example if you add some domains and then go back and delete > them later, further new domains dont get added to these now-vacant > parts of the tree You are right. The algorythm does not prior deleted entries and reuse them. Since we have 23 million directory slots to use, we decided not to bother with looking for empty directory slots. Just create a new one. > > On other (non-vpopmail) virtual mail systems that I have used, the > hashing system is typically much more simple - with the sysadmin > choosing how many levels of hashing were required, and then > just hashing the dirs using the leading portions of the username/domain > > eg "userhash" level of 1 means all user dirs would be hashed like this > exampledomain.com\ > a/<then all the usernames starting with a> > b/<then all the usernames starting with b> > c/<then all the usernames starting with c> > etc > > a "userhash" level of 2 means that user dirs would be hashed like this > exampledomain.com/ > a/aa/<then all the usernames starting with aa> > a/ab/<then all the usernames starting with ab> > a/ac/<then all the usernames starting with ac> > etc > > same sort of system could be used for a "domainhash" > > There is no disputing that this system would end up having some dirs with > more entries than others, but even on a system with many user accounts, > probably two or at the most three level of hashing would prevent any single > dir from becoming excessively large. The current vpopmail system doesn't > seem to balance the dirs evenly anyway, so it is not like we would be > loosing any functionality there. > > Having a logical directory layout like this also simplifies other issues. > Eg recovering from a corruption in the file/db that stores the hashing > info, or moving domains/accounts between servers. Your proposed algorythm is the problem we were trying to solve. One large vpopmail site had broken up their directories like you suggested. But they were having heavy disk I/O which they finally tracked down to the OS walking through the directory structure. So we came up with current system. They both were benchmarked against each other. The winner was to not use more than 300 sub directories in any one directory. Hope that helps explain why it was built this way. Ken Jones inter7.com > > Michael.
