Yeah, maildirs seem pretty effective as a store. Thats actually what I was hinting at (with a link file instead of real links as this is a java program and will be running on platforms which don't support real links). I don't buy into the idea that creating multiple files will cause much more disk thrashing, as a spool file can be scattered all of over the drive too. Although, the open/close efficiency issue is real, BUT I think this can be counteracted with a good full-text index file. Also, thanks to the newer journaling file systems, it would be a lot easier to guarantee that a message is uncorrupted. Although, I definetely think the indexing system should be implemented after a simple maildir implementation is put into place. Anyways, this would just be a step to at least get this into something close to a beta phase. What do you guys think?
-----Original Message----- From: Jason Webb [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 3:02 AM To: 'James Developers List' Subject: RE: IMAP Development Pointers If there is enough interest or need I will write a maildir-style repository. This is used by qmail and Courier-IMAP to great effect and provides folders etc., and it's safe(ish) over networked file systems. The current repositories are less than ideal other than for folder based storage ,particularly the mbox one ;) -----Original Message----- From: Jim Wright [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 5:40 PM To: James Developers List Subject: Re: IMAP Development Pointers Hi Edward, I have University of Washington IMAP on my Linux machine and use an experimental format mx which is as you describe. To quote the docs: . mx This is an experimental format, and may be removed in a future release. ... [snip] mx is somewhat inefficient; the entire directory must be read and each file stat()'d. We found it intolerable for a moderate sized mailbox (2000 messages) and have more or less abandoned it. [snip] There's a general reason why file/message formats are a bad idea. Just about every filesystem in existance serializes file creation and deletions because these manipulate the free space map. This turns out to be an enormous problem when you start creating/deleting more than a few messages per second; you spend all your time thrashing in the filesystem. It is also extremely slow to do a text search through a file/message format mailbox. All of those open()s and close()s really add up to major filesystem thrashing. I was not completely convinced by this. File system devices are getting faster for a start. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
