Hi,

I, like probably many others, signed up for a Linode to run my personal e-mail and web hosting.

My email is using UW imap and I have split my email into two folders (one saved items, one sent items) per year, using the MBX format (like MBOX only with a few features such as a binary header, flags writes without message rewrites, and message lengths to enable efficient mailbox scanning) and dmail for direct MBX delivery (avoid overhead on initial mailbox opens).

For me this is roughly 200MB to 500MB per folder. Now, this is a problem with the current IO tokens, as if I delete a message from early in a folder it runs out of IO tokens during the mailbox close. If I delete messages in multiple mailboxes during one session, well, things get very bad. I'm considering a switch to dovecot(1.0rc5) + maildir to avoid the heavy IO on deletes (hence enabling ext3 directory indexes, as per my other post -- to then avoid heavy IO on some other operations), but for now, I'm also wondering if there's any chance of improvements to the IO token limits or system.

Now I've only recently signed up to Linode, and I see that the plans have improved greatly (especially in memory and disk) over time.

However, I don't see any reference to the IO tokens having been increased.

I have really 3 questions (the one in the topic, and two others);

1. Is there a chance of an increase for all users, as the hardware speed is likely to have increased?

2. How about increasing tokens for users on higher plans, as there is less contention and yet still the same system IO? As I understand it, even on a Linode 200, with a lower contention ratio, I'm still receiving as many IO tokens as I would if I'd signed up for a Linode 100.

3. How about making 'unused' IO tokens available to other users? I have implemented resource sharing (for bandwidth) in other environments via a linear increase + exponential decay algorithm, which I've found to work quite well (and believe generally permits more efficient sharing of resources, fairness between those contending for the resources and better aggregate throughput). Basically:

    decay_factor = decay_percentage / 100.0

    new_balance[user] = old_balance[user] * (1.0 - decay_factor) +
                        sum(old_balance) * decay_factor / user_count +
                        alloc_capacity_per_interval / user_count 

edit: Formula was initially wrong.

Linode.com are currently testing Xen as a replacement for UML. The I/O fairness problem will most likely be solved in a different way so major changes to the I/O tokens code are unlikely.

The tokens could be increased on bigger Linodes but doubling your tokens only delays the arrival of trouble. The I/O tokens are a method of stopping one Linode monopolising host I/O. If you're running out of tokens, then something is wrong. In your case, the Linode file system isn't up to manipulating 500MiB mbox files.

Maildir is the way to go. My 150MiB of mail runs on a Linode 100 without problems. I use reiserfs rather than ext3 - just because the Linode.com distros and tools don't use/support it doesn't mean you can't roll your own. I run reiser over LVM for everything except the root partition.

_________________
/ Peter

I just wanted to second the idea of using Maildir as opposed to MBOX or its relatives.

While some filesystems handle many-small-files better than others, I wouldn't worry too much about it.

You can't have my iotokens. Not if you only want them because you're running UW-IMAP. As others have suggested, and you seem to already know you should install something that works with maildir as its much more efficient.

At any rate, my understanding of the io_tokens situation is that the default limit is set such that you will already be using more than your fair-share by the time the limiter kicks in - ie you're already impacting the performance of other linodes. If you keep hammering 500MB MBOX files don't be surprised if your limit drops however...

Well, I've now done the MBX -> MBOX -> Maildir++ transition, which was very painful due to (you guessed it!) IO tokens.

The current IO token algorithm does permit hammering the machines as the peak number of tokens is very large (eg. if many otherwise idle systems have updatedb scheduled to run at the exact same time, this would be bad), but its refresh rate seems a little low.

It also seems to be based on the raw number of IOs, which is an (unintentional or intentional?) encouragement to do bigger IOs (whereas MBX on UW-IMAP does smaller, scattered IOs; the Dovecot indexes will hopefully lead to larger individual IOs in general operation).

Either way, Dovecot + Maildir++ + 4k block reiserfs looks like once I've done my initial resync of my IMAP client it will keep the IO token use to a minimum. However, I would still like a response to the ideas in my original post if someone from Linode has the time

Actually, ext2/3 without dir_index are _abysmal_ at handling large Maildir++ mailboxes. Thats why I initially installed using MBX format, as the filesystem that was installed by default would have _really_ not handled my mailbox in a Maildir++ format. However, the problems with the linear diectory searches would have resulted in larger IO operations and wasteful CPU usage, which probably would have not hit the IO token limiter so much so it may have been more usable on a Linode despite being wasteful of actual machine resources.

But as per my above reply, I've gone for Dovecot + reiserfs w/4k blocks and noatime/notail + Maildir++ -- based on how the resources are spilt on the Linodes this looks like it will give best performance.