-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Feb 2009, Allen Belletti wrote:
I would add that having fewer, larger files should make backups much
more feasible. There's a certain amount of overhead for each file
That's true for full backups. I don't defend Maildir, esp. because
Hi Timo
I have a few comments. Please just disregard them if I have
misunderstood your design.
Regarding your storage plan
I find it very important that users can be stored in different locations
because:
1. Discount users could be placed on cheap storage while others are
offered premium
I would add that having fewer, larger files should make backups much
more feasible. There's a certain amount of overhead for each file
operation (especially for us GFS people!) and reducing the number of
files will reduce that overhead.
Right now our backups (done via rsync) take a pretty scary
On Thu, 2009-02-12 at 11:29 +0100, Mikkel wrote:
Hi Timo
I have a few comments. Please just disregard them if I have
misunderstood your design.
Regarding your storage plan
I find it very important that users can be stored in different locations
because:
This you misunderstood. The
Timo Sirainen wrote:
This is about how to implement multiple msgs/file dbox format. The
current v1.1's one msg/file design would stay pretty much the same and
it would be compatible with this new design.
Out of curiosity, what's the advantage to going to multiple messages per
file? Wouldn't
On Wed, 2009-02-11 at 14:32 -0800, Seth Mattinen wrote:
Timo Sirainen wrote:
This is about how to implement multiple msgs/file dbox format. The
current v1.1's one msg/file design would stay pretty much the same and
it would be compatible with this new design.
Out of curiosity, what's
On Wed, 2009-02-11 at 17:35 -0500, Timo Sirainen wrote:
On Wed, 2009-02-11 at 14:32 -0800, Seth Mattinen wrote:
Timo Sirainen wrote:
This is about how to implement multiple msgs/file dbox format. The
current v1.1's one msg/file design would stay pretty much the same and
it would be
On Wed, 2007-05-16 at 20:27 +0200, Gunter Ohrner wrote:
Am Mittwoch, 16. Mai 2007 schrieb Timo Sirainen:
Yes, I think treating mailboxes similary to keywords is ideal. There
Except if you want to handle some mailboxes in a special way it's
easier if they're separated on disk. Such as
Am Samstag, 19. Mai 2007 schrieb Timo Sirainen:
1) Have another human readable mailbox ID - name mapping file which
is used if the binary index is corrupted. If mailboxes are
created/deleted/renamed often, this would just slow things down. Might
be a good idea optionally though.
The Mailbox
On Sat, May 12, 2007 9:10 am, Timo Sirainen [EMAIL PROTECTED] said:
Fast copying
Would be nice if copying a message from one mailbox to another wouldn't
require actually reading+writing the whole message contents. But I can't
really figure out how to implement this without
On Wed, 2007-05-16 at 06:40 -0400, Bill Boebel wrote:
Although one possibility would be treat mailboxes a bit similarly than
keywords. So that when a message is copied to another mailbox, the
message in dbox file is updated to contain information that it exists in
such and such mailboxes.
Would be nice if copying a message from one mailbox to another
wouldn't require actually reading+writing the whole message
contents. But I can't really figure out how to implement this
without requiring that there is only a single dbox storage which
contains the mails for all the mailboxes, and
On Wed, 2007-05-16 at 07:47 -0400, Charles Marcus wrote:
Although one possibility would be treat mailboxes a bit similarly
than keywords. So that when a message is copied to another mailbox,
the message in dbox file is updated to contain information that it
exists in such and such
I don't think anyone uses dbox currently, so the whole format could
still be redesigned. So I was thinking about doing two major changes:
1. Rely on index files a lot more. The flags are already stored in index
files, so there's no need to waste I/O updating them to dbox files all
the time. They
14 matches
Mail list logo
