[Dovecot] dbox support state
hi, what is the current state of dovecot dbox support? is it stable, fast and usable? is it have current advantage over maildir or it will only have when it'll be optimized? is it worth to choose as a default mailbox format in a new dovecot install? thanks. yours.
-- Levente "Si vis pacem para bellum!"
On Wed, 2006-12-13 at 00:52 +0100, Farkas Levente wrote:
hi, what is the current state of dovecot dbox support? is it stable, fast and usable? is it have current advantage over maildir or it will only have when it'll be optimized? is it worth to choose as a default mailbox format in a new dovecot install?
I did pretty heavy stress testing for it some months ago, but I haven't tried since then if it's still working. I'm planning on moving my own mails to it when I have enough free time (should first figure out how to make procmail use Dovecot LDA).
I think it should be pretty fast already. With my imaptest client that kept fetching, appending and expunging messages using 5 connections it was a lot faster than maildir. Actually maildir really seems to suck when doing that kind of operations, even mbox is much faster with it..
One optimization left for it would be to not store flags and keywords to the dbox files at all, but keep everything in index files. Once I get that implemented, I'll start benchmarking it. Of course the problem with that is that it relies on index files completely then.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 21 Dec 2006, Timo Sirainen wrote:
One optimization left for it would be to not store flags and keywords to the dbox files at all, but keep everything in index files. Once I get that implemented, I'll start benchmarking it. Of course the problem with that is that it relies on index files completely then.
IMHO this is not good for disaster recovery and makes life needlessly hard in such case. Esp. when both files become out-of-sync, you need a cunning tool to re-construct any good state, rather than a simple "REINDEX". This should apply to each kind of "index" file. Also, consider upgrades to newer index file formats etc.pp.
Are there really that many writes of message attributes? I mean, there is only an improvement because you have just one write into the indexes rather than two, one to the indexes and one into the message. You've wrote that you reserve space for the flags in mbox, in case they get updated, so you reduce the probability to rewrite the whole mbox for each flag. Doing so should apply to dbox as well?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRYuF4S9SORjhbDpvAQJGRgf/eaPv8j+oZkep2zOmODI/qiPqexL+AXn4 Qs89REpzxhMTr64q4qDmaZcXzjTQrlkp1qxYC8htkP/Ol58w1SeC4vgCtFXQ18UX 8e6h5y1OEEPfMatf+BTUe8CfDwV0ALYGmRvhR1RRB4o6yV37R442aoDaHa/8sd4K ZexCJWS2PGTqEZsro4crxJ0As+UiqtanpAYFM0YduwgJ8PXS9oawAMuGviB6qL7+ RTggBSzmpVMdb07FdYFBTmSZO9c9H1KJ7iiRXaN3iapnw/JbxJHgrsWeIUf0OgBk fKaTwa4UppeUQv4f7QbqmNn2u3+ovXD35Dal+RUccS5dOg2lW74hqA== =BFHK -----END PGP SIGNATURE-----
On 22.12.2006, at 9.14, Steffen Kaiser wrote:
One optimization left for it would be to not store flags and
keywords to the dbox files at all, but keep everything in index files. Once I get that implemented, I'll start benchmarking it. Of course the
problem with that is that it relies on index files completely then.IMHO this is not good for disaster recovery and makes life
needlessly hard in such case. Esp. when both files become out-of- sync, you need a cunning tool to re-construct any good state,
rather than a simple "REINDEX". This should apply to each kind of
"index" file. Also, consider upgrades to newer index file formats
etc.pp.
I was thinking that before doing this, the index file handling should
be hardened more. So that if it detects a corruption, it tries really
hard to preserve the flags and write a new valid index file, instead
of just rebuilding it like it does now.
Are there really that many writes of message attributes? I mean,
there is only an improvement because you have just one write into
the indexes rather than two, one to the indexes and one into the
message.
And with some updates to index file code, it would eventually be
possible to just write to dovecot.index.log file and update
dovecot.index only once in a while. This way the disk writes would be
really minimal, since it only needs to writes to a single file.
Anyway, this would be optional, so that you could decide if the
performance increase is worth the potential problems. Also it would
be possible to still update the flags once in a while, so that if the
indexes get trashed you'd lose only the last day's (or so) flag changes.
I don't know how much of a difference it would make in real world,
but anything that reduces disk I/O is good :)
You've wrote that you reserve space for the flags in mbox, in case
they get updated, so you reduce the probability to rewrite the
whole mbox for each flag. Doing so should apply to dbox as well?
Yes, there's space reserved for flags and keywords in dbox files. It
doesn't even support moving data around like mbox does.
Timo Sirainen wrote:
On Wed, 2006-12-13 at 00:52 +0100, Farkas Levente wrote:
hi, what is the current state of dovecot dbox support? is it stable, fast and usable? is it have current advantage over maildir or it will only have when it'll be optimized? is it worth to choose as a default mailbox format in a new dovecot install?
I did pretty heavy stress testing for it some months ago, but I haven't tried since then if it's still working. I'm planning on moving my own mails to it when I have enough free time (should first figure out how to make procmail use Dovecot LDA).
that's another good question. can we use anything with dovecot lda procmail or sieve? or in this case we've no choise:-(
-- Levente "Si vis pacem para bellum!"
participants (3)
-
Farkas Levente
-
Steffen Kaiser
-
Timo Sirainen