[PATCH] MANUAL.rst: Improve with Perf tips and SSL notes

Daniel Shahaf d.s at daniel.shahaf.name
Sat Jul 9 18:54:36 BST 2011


Sebastian Spaeth wrote on Sat, Jul 09, 2011 at 19:35:23 +0200:
> On Sat, 9 Jul 2011 00:19:31 +0300, Daniel Shahaf <d.s at daniel.shahaf.name> wrote:
> > While offlineimap.conf calls SQLite backend experimental, so should this
> > tip, I believe.
> 
> Sure, can do so. Although I would really love to move this out of
> experimental state at some point after the next release. I have been
> running it a long time now and I feel pretty confident that it is not
> less safe than using the plaintext one. Marking it as experimental will
> cause people to not even try it out :-).
> 

I don't know the implementation of either backend, so I can't really
comment here.

I did enable the SQLite backend for one of my accounts yesterday.

> > Could you explain what might be the repercussions of disabling fsync?
> > 
> > ie, if I disable fsync and the power goes out while some changes have
> > not been flushed, will something be corrupted?  And if so, how easy
> > would it be to detect,repair that corruption?
> 
> There is 2 areas where this fsync setting is used. One is when writing
> out messages to the local Maildir, the default here is fsync=True. So we
> will make sure that a message has actually been written out to disk
> before we note it in the status cache. If False, writing of several
> messages to disk could potentially happen in one bigger lump (which
> obviously is good for performance). A crash without fsync here could
> obviously mean that we have added a message to the cache but not written
> it out to disk yet. In that case, the next run could think it had been
> deleted and delete the message on the server too. So, there is possible
> data loss in case of crash (a network gone bad won't be enough, but a
> crash could do it).

I think this point ("fsync=False could lead to lost mail if the disk
cable drops at a bad time") should be documented.

> The other area is fsync for writing out the LocalStatus cache. We
> would wait till the megabytes of data have been written out before we
> start writing out the message or proceed to the next message. A loss
> here would not be that bad (in the case of IMAP<->Maildir we can
> reconstruct the LocalStatus cache), and in IMAP<->IMAP case, it would
> probably mean a few duplicated messages at worst. (Fsync in the sqlite
> case won't matter for LocalStatus which will always write out stuff on
> time, I believe).
> 

So, a little inconvenience, and perhaps a cache rebuild, but no data
loss.  Okay.

> So, it really depends on your security needs and willingness to tradeoff
> speed vs crash-safeness.
> 

Indeed.  Thanks for the very detailed answer!

> > > +Security and SSL
> > > +================
> 
> > What about 'openssl s_client'?  When I run it, 
> >         New, TLSv1/SSLv3, Cipher is AES256-SHA
> > is part of the output.
> 
> Interesting, I have a hard time interpreting this:
> 
> $ openssl s_client -connect sspaeth.de:22
> 
> CONNECTED(00000003)
> 4440:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
> protocol:s23_clnt.c:607:
> 

ssh != ssl

> And connecting to my mail server leads to connection refused. But
> something like this would be nice indeed, yes.





More information about the OfflineIMAP-project mailing list