5 messages in net.sourceforge.lists.courier-maildrop[maildropl] Compressing live Maildir(...
FromSent OnAttachments
Ronan MullallyOct 18, 2004 8:35 am 
Jay LeeOct 18, 2004 8:11 pm 
Ron JohnsonOct 18, 2004 9:14 pm 
Ronan MullallyOct 19, 2004 1:21 pm 
Ron JohnsonOct 19, 2004 6:52 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[maildropl] Compressing live Maildir(++) directoriesActions...
From:Ronan Mullally (ron@iol.ie)
Date:Oct 18, 2004 8:35:41 am
List:net.sourceforge.lists.courier-maildrop

I tried posting this to the Courier IMAP list last week but got no response. Maybe this is a better venue...

Has anybody considered implementing compression within the Maildir backend of the Courier IMAP/maildrop? It strikes me that this might be reasonably simple to implement. Granted, it has major CPU implications, but conversely could result in siginificant storage savings.

I've been toying with the following ideas:

- Modify maildrop to compress files as they're written to the Maildir.

- possible refinement here - don't compress files which match certain criteria (e.g. compressed attachments) - differentiate un/compressed files by naming compressed files .gz for example

- Another possible refinement - use and external script to compress old messages / folders

- Modify the maildir backend for Courier IMAP to recognise these compressed files and uncompress them as they're opened.

The main overhead here is compression rather than de-compression, but given that SMTP deliver isn't seen directly from the users point of view I think this might be acceptable. It might be possible to minimise this overhead by enforcing a max message size limit to prevent a 100MB file from hogging CPU.

This will no doubt have an impact on some IMAP functions - sorting will be slowed down as each file that's accessed needs to be compressed, but the typical 'show me message X' transaction shouldn't experience much of an overhead.

I know this could be accomplished transparently using filesystem level compression, but that's not an option for the scenario I have in mind.

Has this been attempted before?

-Ronan