Well, doesn't matter if it's NFS or not. It still looks as if Dovecot
process was stuck for 45 seconds, most likely waiting for disk I/O to
finish.. What happens is something like:

1. Get the current time ("now")
2. See if lock file exists
3. Create lock file
4. fstat() the created lock file
5. Log a warning if fstat's ctime differs from "now" more than 30
seconds. (Actually I think the 30 seconds threshold is way too generous,
it should be less than 1 second usually.)

So steps 2 and 3 took 45 seconds to finish. Basically I guess the disk
I/O load was very high at that time, or alternatively there was some
unintentional delay caused by iSCSI (kernel/network bug/problem).

On Sat, 2011-11-05 at 00:57 +0100, Maria Arrea wrote:
> Timo, we are not using NFS, we use remote iSCSI volumes with ext4.
> 
>  Regards
> 
>  Maria
> 
> ----- Original Message -----
> From: Timo Sirainen
> Sent: 11/04/11 09:59 PM
> To: Maria Arrea
> Subject: Re: [Dovecot] Dot Lock timestmap, users disconnections from roundcube
> 
>  On Thu, 2011-11-03 at 10:54 +0100, Maria Arrea wrote: > Hello. > > We are 
> running dovecot 2.0.13 with mdbox+zlib on RHEL 5.7 x64, ext4. We use NTP. 
> Indexes are in a iSCSI raid 10, mailboxes in raid5. No NFS. We have detected 
> that sometimes all users get disconnected from roundcube at the same time. In 
> dovecot logs we hundreds of lines like this: > > Nov 3 09:23:07 buzon 
> dovecot: imap(mcrivero@mydomain): Warning: Created dotlock file's timestamp 
> is different than current time (1320308587 vs 1320308542): 
> /buzones/mydomain/03/67/mcrivero/subscriptions I did several fixes related to 
> this, but they were already in v2.0.10. Note the time difference of 45 
> seconds. > Nov 3 09:23:07 buzon dovecot: imap(mcrivero@mydomain): Connection 
> closed bytes=0/295 The dotlock warning isn't related to this. My guess: NFS 
> was being extremely slow here, some operation took 45 seconds and Roundcube 
> decided to abort before that. The "timestamp is different" check doesn't work 
> 100% correctly if the f
 il
>  esystem operations take more than a second.


Reply via email to