[Dovecot] mail_fsync=never doesn't work?

[Timo Sirainen]

On 27.9.2010, at 20.13, Attila Nagy wrote:

>>> I've searched for some more examples and each of them were like this
>>> one. It seems that Dovecot copies the subscriptions file to this
>>> temporary file and then fsyncs it. And the question also arises: why?
>> Fixed: http://hg.dovecot.org/dovecot-2.0/rev/4959db811d29
> Thanks! But shouldn't "Avoid fsyncing subscriptions file when it doesn't change or if mail_fsync=never." be "Avoid re-writing subscriptions file when it doesn't change and fsyncing it if mail_fsync=never."?
> I mean (I haven't read the code context) if you know that it does not change, why write?

Ah, but I don't know :) The possibilities are:

a) Open a temp file and start writing new subscriptions to it. If we notice that the subscription is there already, abort and delete the temp file. This is how it works now.

b) Read the subscriptions to find out if it exists there, and if it doesn't then re-read it and start writing. Seems a bit wasteful.

c) Same as b) but read it into memory to avoid re-reading (possibly up to n kB to avoid wasting too much memory).

And since normally clients don't issue SUBSCRIBE commands unnecessarily, b) and c) seem like a lot of extra trouble. The only problem here is autocreate plugin which sucks in any case. Better to just fix that in v2.1.

>> Also http://hg.dovecot.org/dovecot-2.0/rev/432208994270 avoids multiple
>> write() syscalls. Although it still does writes to temp file even when
>> it's not necessary, but that's again annoyingly too much trouble to
>> prevent..
> Hmm. It may be trouble, but inspecting a user's pop3 login

Just disable autocreate plugin for pop3:

protocol !pop3 {
  mail_plugins = $mail_plugins autocreate
}

> (no fsync now) starting with the first appearance of subscription.lock, ending with the last I see more weird stuff:
> 62900 pop3     1285613658.763692 NAMI  "/home/hm01/user2/Maildir/subscriptions.lock"
> 62900 pop3     1285613658.763777 RET   lstat -1 errno 2 No such file or directory
> [...]
> 62900 pop3     1285613658.783839 CALL  unlink(0x8010b0a40)
> 62900 pop3     1285613658.783865 NAMI  "/home/hm01/user2/Maildir/subscriptions.lock"
> 62900 pop3     1285613658.784045 RET   unlink 0
> 
> I see four(!) rewrites of the subscriptions file between the two.

That's because you have 4 autosubscribe entries. The current code doesn't allow doing multiple subscription changes at once. But anyway, again, the problem here is the autocreate plugin. I hated even adding it to included plugins, but too many people just wanted it.

(v2.1 way of handling it would be to have kind of virtual mailbox names that are always listed, but actually physically created only when it's opened the first time. That way you could also change them and if user has never actually accessed a removed mailbox it would automatically also disappear.)