2 ms·
I think the best system would be one inbetween mbox and maildir. You specify a filesize limit of say "10MB". Emails are repeatedly added to the same file, until
by mike-cardwell 15y ago
I think the best system would be one inbetween mbox and maildir. You specify a filesize limit of say "10MB". Emails are repeatedly added to the same file, until it hits 10MB, then a new file is created. Emails larger than 10MB would not be split over multiple files. An index is kept of all of the messages. When a message is deleted, rather than immediately removing it from the file and blocking like most mbox implementations work, it should just be flagged as deleted in the index. A background process can clean up these messages when the file is not in use.
- ams6110 15y agoWhat you describe is essentially a database for email. You might have a look at http://www.dbmail.org/ http://www.dbmail.org/
- mike-cardwell 15y agoThis is true. Maildir and mbox are also essentially databases for email.
- ams6110 15y agoOK. Maybe I should have said DBMS? I'm speaking specifically about the management of the back-end storage files, e.g. splitting storage over multiple size-limited files, tracking and re-using free space, etc. are all things that DBMSs provide, without a need to reinvent such things for the purposes of storing email. If there's a better term to describe this I'd be glad to learn it.
- JoshTriplett 15y agoSeems like in such a system you've gone to a lot of work to recreate the purpose of a filesystem: to keep the data of different files separate from each other. Why do you want to keep emails together in 10MB chunks?
- mike-cardwell 15y agoTo address the limited inode issue