James Whitt wrote:
In the next three months, I will more than likely start looking into writing a script of some kind to interact with .dir-control so that I will be able to update the hashed directories to recognize spots that can be filled in previous directories. Do you think this is a feasible goal (at this point I haven't looked into how the .dir-control file works since it will be a later project for me).
I think you will find that .dir-control isn't very smart. If you reset it so it starts re-using empty directories it will blindly double the number of entries in existing full ones. You might consider something that is frequently run which resets .dir-control to keep it in a proper state most of the time. That doesn't look very easy to do.
I see two possibilities. Either add some kind of garbage collection to .dir-control where it records the number of entries deleted from existing directories and prefers to fill existing directories before it creates entries in new ones. This has to be built into of vpopmail.
The other option would be to write a 'de-fragment' utility for the directory structure.
For CDB
Scan the directory structure from the oldest searching for an entry that is not full. When one is found {
figure out which entries to move from the last (newest) directory into the oldest to fill it.
create a new users file that reflects the moves.
lock the users file or table for the domain.
actually move the entries.
rename the new users file into place.
rebuild the .cdb file.
adjust the .dir-control file.
unlock the users file. }
Repeat until there are no directories with free entries except the last.
For a database back end.
Scan the directory structure from the oldest searching for an entry that is not full. When one is found {
figure out which entries to move from the last (newest) directory into the oldest to fill it.
lock the users table.
actually move the entries.
adjust the table.
adjust the .dir-control file.
unlock the users table. }
Repeat until there are no directories with free entries except the last.
You should know what you are going to do before you start the lock to keep the time the file is locked as short as possible.
Hope the system doesn't go down between moving the directory and updating the users file! You probably don't want to update it for every mail account moved because it is too inefficient. You don't want to do it very late because then the domain is locked out of receiving mail, or serving pop/imap clients. I'm guessing processing all entries that need to be moved to fill one directory is a good granularity. It makes an easy to implement algorithm anyway...
