[Dovecot] Overly long email of miscellaneous Dovecot migration questions

[Mark Moseley]

On Wed, Mar 17, 2010 at 1:09 PM, Timo Sirainen <tss at iki.fi> wrote:
> On Wed, 2010-03-17 at 12:15 -0700, Mark Moseley wrote:

>> From the wiki and from the
>> thread, it sounds like this just affects index files. One thing I
>> didn't see in the thread (though it'd be easy to miss in a thread that
>> long) is whether performance suffered horribly with 'noac' on a
>> *separate* index mount (the mentions I can find where they tried
>> 'noac', it was on the entire mail store, not a separate index mount)
>> -- though doing 'noac' on anything seems like a recipe for disaster.
>
> noac increases the NFS traffic for indexes by something like 10x,
> regardless of how it's mounted.

Yeah, this would be something of a last act of desperation. Hopefully
if it comes to that, having a separate indexes-only NFS mount that's
the *only* thing mounted with noac would make it barely tolerable. Is
it safe to say that with 'noac' but using 'sync' wouldn't help? And
I'm assuming it's file attributes being cached that leads to
corruptions, so would leaving acdirmin/max at their default values but
lowering acregmax to 1 (not sure if 0 disables it completely) prevent
corruption in all but the most extremely concurrent cases? Again this
would be a last ditch thing, esp considering how hot our Filers run
already -- adding another chunk of cpu% would put the nail in the
coffin.

It sounds like a local cache would be far preferable. Since it's
*just* IMAP, I'm guessing it won't be too huge. I'm thinking I
dedicate a local partition, mount it *with* atime, and then cron
something to delete all index files that haven't been accessed in a
certain amount of time (a week, 2 weeks, a month, whatever). I'd use
something like this:
mail_location=....:INDEX=/path/to/index/partition/Indexes/%2Mu/%2.2Mu/%u
to keep from getting too many entries in a single
directory/subdirectory.


>> Another extreme option might be to just keep indexes on local disk
>> only. Obviously users hitting another server wouldn't benefit from the
>> other server and it'd incur updates to the indexes but they seem
>> somewhat minimal -- in sane cases at least where the number of
>> newer-than-the-index messages is reasonable. With aggressive load
>> balancer stickiness at maybe a /24 netblock level, I'd be able to keep
>> people localized for a little while (with no way around people
>> accessing the same mailbox from home and work). Am I underestimating
>> the costs of incremental index updates on local disks? In testing, tt
>> seemed like dovecot was pretty conservative in disk accesses/reads
>> when updating. I'm hoping the 95%-of-the-time worst case will be
>> someone hitting the same mailbox from two locations, so they'd be
>> hitting at most two servers. With local index caches, I'm mildly sure
>> I could live with that (esp if I can talk my way into an SSD on each
>> one). Am I being too naive?
>
> I don't know if anyone has run local indexes in larger setups, so I
> can't really give any good answers. The worst case of rebuilding the
> whole index isn't anyway any worse than what Courier has to do every
> time.

I'll check it out. And if we go that route and I'm still sane at the
end, I'll be sure to report back :)


>> I'll play around with that more. So it should be possible to have more
>> than one private 'hidden=no; list=yes' namespace that'd show up in a
>> mail client's subscribable folders list?
>
> Yes. And probably hidden=yes is better, since it doesn't really need to
> show up as a separate namespace for clients (even though most would
> ignore it anyway, but some might show it a bit weirdly).
>
>> Offhand, before I start sifting
>> through source code, is Dovecot on a 32-bit system limited to a 32-bit
>> -- i.e. 2 gig -- limit on quota size like Courier is?
>
> Quota is always 64bit. And Dovecot usually tries to enable 64 bit file
> offsets for 32 bit systems too, and then there aren't any 32 bit file
> size limits anywhere.

Excellent. Not that I really want to give out +2gb mailboxes but now I
won't have to explain for the 30th time to marketing folks why I can't
raise someone over the 2gig quota.


>> >> If we're going to have to live with
>> >> users complaining about a one-time redownload of just post-conversion
>> >> mail, I'll need to get started convincing the higher-ups that that's
>> >> life.
>> >
>> > Check what the new Courier POP3 UIDLs look like. If all of them are maildir base filename, setting pop3_uidl_format=%f should make this conversion easy. Just run it through once to get old UIDLs converted and then you don't need to worry about it, because both Courier and Dovecot give the same UIDLs. But I never really understood how Courier assigns new UIDLs, sometimes it seems to use the filename and sometimes not..
>>
>> So do you mean keep pop3_uidl_format=%f basically forever? That'd work
>> for me, but are there any big implications, performance-wise or other,
>> of not using the default "%08Xu%08Xv"?
>
> %f is at least more reliable, because it's not fully guaranteed that
> UIDVALIDITY+UID never changes (although in practice they don't). If they
> do, then POP3 UIDL changes and clients redownload mail. The only
> disadvantage is the somewhat larger UIDLs causing a bit more and network
> bandwidth usage.
>
> It's also possible to set pop3_save_uidl=yes, and that's probably a good
> idea also, so that whenever UIDL is sent to client, it's also saved to
> dovecot-uidlist. That allows you to later change pop3_uidl_format
> without changing existing UIDLs.

Ah, I think I didn't quite get it the first time around. I was
thinking that just setting pop3_uidl_format would be enough. But I see
now that I've got to have a sequence base in dovecot-uidlist created
by the conversion script first. And only if I've run the conversion
script relatively recently (and the mailbox doesn't get any of the
seen-by-Courier and unseen-by-Dovecot emails removed (i.e. via
imap/webmail) so the ordering is identical will things not get
redownloaded. It seems like it'd be rare for someone to delete a
message from their POP3 mailbox via IMAP/webmail, so I'm going to
cross my fingers that this takes care of 99% of the cases.

BTW, my Courier version is pretty recent and it seems to be giving
back just this format: pop3_uidl_format = UID%u-%v

Just to be sure I'm interpreting this right (I say that a lot), if I
use 'pop3_save_uidl=yes' from the beginning, after everyone is 100%
migrated to dovecot on both POP3/IMAP, I should be able to change back
to the dovecot-style UIDLs without triggering a re-download for any
POP3 leave-mail-on-server people?


>> Does that require a
>> corresponding change to the conversion script?
>
> No.
>
>> So I'd have Dovecot use
>> the Courier-style UIDLs, run the conversion to get the old UIDLs (i.e.
>> anything not using the Courier "%f", which is a bit) into
>> dovecot-uidlist, and then not worry about any new mail, since clients
>> will see the same UIDLs (and dovecot will just update dovecot-uidlist
>> with those UIDLs the first time they log into Dovecot's POP3)?
>
> Yeah.
>