cyrus-imap buildin: sse extention

2020-06-28 Thread Sergey
Hello.

I saw what Cyrus-IMAP use SSE:

Hardware support:
   SSE4.2: yes

Can Cyrus-IMAP be running on systems without SSE4 at this case?
If no, can I set limit to SSE2 ?

-- 
Regards,
Sergey

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: cyrus-imap buildin: sse extention

2020-06-28 Thread ellie timoney
Hi Sergey,

> Hardware support:
>SSE4.2: yes

This is detected for a hardware implementation of the CRC32c algorithm.  Cyrus 
doesn't actually use it though, because it's not compatible with the existing 
CRC32 algorithm: i.e. for the same input, it produces a different checksum, 
which would break everything on a system with pre-existing data.

If you _want_ to use the hardware CRC32c algorithm on a brand new deployment 
(and know what you are doing), I believe at this stage you would need to patch 
Cyrus to use it -- the code is there, but it is never called.

> Can Cyrus-IMAP be running on systems without SSE4 at this case?

Yep, it'll work just fine.  The hardware CRC32c code will simply not be 
compiled, which, since it isn't used anyway, will have no effect.

> If no, can I set limit to SSE2 ?

There's currently no configurability for this at all.  I don't know if it's 
even possible to implement the same algorithm with SSE2.  At the moment I 
assume that, since it's looking for SSE42 specifically, then that means that 
the hardware feature it needs is probably only available in SSE42.

Cheers,

ellie

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: Newly arrived mail is marked as "read"

2020-06-28 Thread ellie timoney
Hi,

I'm not sure, but it kind of sounds like your mailbox's index version is too 
old?

Around 2.4, the storage of the mailbox owner's seen state was moved from the 
seen databases to the cyrus.index.  (i.e. nowadays the seen database only 
stores the seen state for _other_ users who have been given access to a mailbox 
-- which is often nobody).

If your mailbox indexes have not been updated yet, then they won't have a field 
to record the owner's seen state, which might result in the behaviour you're 
seeing?

To update your mailbox indexes to the latest version, you can use the "-V max" 
option with the reconstruct utility.  The upgrade documentation for 3.0 
(https://www.cyrusimap.org/3.0/imap/download/upgrade.html#reconstruct-databases-and-cache)
 mentions that this may take a long time, so maybe you already saw this but 
haven't gotten to that stage yet.

You should definitely take note of the warning on that page though, and 
consider upgrading to at least 3.0.11 rather than 3.0.7.

Hope this is helpful!

Cheers,

ellie

On Fri, Jun 26, 2020, at 10:43 PM, Cheng-Jih Chen wrote:
> I'm in the process of testing the upgrade from a CentOS 6 box running 
> 2.3.16 to a CentOS 8 box running 3.0.7.
> 
> The upgrade has been less troublesome than expected, but I'm seeing a 
> strange problem with newly received mail being marked as "read" even 
> though they have not been opened by the client.  This is the case for 
> both mail sent locally as well as mail received externally (Gmail).
> 
> Can anyone point me in the right direction on where to look to fix this?
> 
> Thanks.
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus