Solving Inode Exhaustion in Dovecot: Maildir vs. mdbox

The Inode Wall

You are monitoring your mail server and notice that disk space is plentiful, but the filesystem is reporting it is full. A quick check of df -i reveals the culprit: you have run out of inodes. In a standard Dovecot setup using Maildir, every single email is stored as an individual file. While this is robust, a few power users with hundreds of thousands of messages can effectively paralyze a server by consuming the entire inode table.

Beyond inode pressure, Maildir creates a secondary bottleneck during maintenance. Running rsync or a filesystem-level backup on a directory containing 500,000 small files is agonizingly slow because the OS must perform a metadata lookup for every single message. The solution is often a shift to mdbox.

How mdbox Changes the Storage Model

While Maildir treats the filesystem as the database, mdbox treats the filesystem as a container. Instead of one file per message, mdbox packs multiple messages into a few larger files. It uses a separate index to track the exact byte offset and length of each message within those files.

This architectural shift provides three immediate benefits:

• Inode Efficiency: Thousands of messages are collapsed into a handful of files, virtually eliminating inode exhaustion.
• Faster Backups: Tools like tar or rsync handle a few large files significantly faster than millions of tiny ones.
• Reduced Metadata Overhead: The filesystem spends less time traversing directory entries.

The Trade-offs of Packed Storage

Moving to mdbox is not a free upgrade; it introduces new operational considerations. The most significant is corruption risk. In Maildir, a corrupted file ruins one email. In mdbox, a corrupted block in a dbox file can potentially affect multiple messages.

Additionally, disk space reclamation differs. In Maildir, deleting a message deletes a file, freeing space immediately. In mdbox, deleting a message simply marks the space as available in the index. The actual disk space is not reclaimed until a purge operation is triggered, which rewrites the file to remove the gaps.

Example: Measuring the Migration Impact

To decide if mdbox is right for your environment, you can test the difference using a sample mailbox. Assuming you are running Dovecot 2.3.x, you can compare the footprint of a single user's mail.

Step 1: Baseline Maildir Metrics
Run these commands as a user with read access to the mail store (typically vmail or root):

# Count files (inodes) for a specific user
find /var/mail/vmail/user1/cur -type f | wc -l

# Time a directory listing
time ls -f /var/mail/vmail/user1/cur > /dev/null

Step 2: Migration via doveadm
Do not move files manually. Use doveadm sync to migrate the format while preserving UIDs and flags. This should be run on the server hosting the Dovecot instance:

# Change the mailbox format in your configuration to mdbox for the target user
# Then sync the mailboxes
doveadm sync -u user1

Step 3: Post-Migration Metrics
Repeat the file count. You will see the file count drop from thousands to a small constant (usually 1-5 files per mailbox), regardless of the number of messages.

# Verify message count remains identical
doveadm mailbox status user1 INBOX

Implementation Risks and Verification

When implementing this change, be aware that index files are critical. In mdbox, the index maps the message to the file offset. If you delete the index files manually to "fix" a glitch, Dovecot must perform a full resynchronization of the dbox files, which is CPU and I/O intensive for large mailboxes.

To verify your configuration before restarting the service, always run the config check command:

# Run as root to check for syntax errors
dovecot -n

If you need to roll back a migration, you must use doveadm sync again to move the messages back to a Maildir-configured destination. A simple cp or mv will not work because the underlying storage formats are fundamentally different.

Summary Decision Matrix

Metric	Maildir	mdbox
Inode Usage	High (1 per message)	Low (Few per mailbox)
Backup Speed	Slow (Metadata heavy)	Fast (Sequential I/O)
Corruption Impact	Isolated to one message	Can affect multiple messages
Space Recovery	Immediate on delete	Requires Purge