Hello Timo,
I'm running
a single instance of dovecot-2.1.15 on a single host running 8.3-RELEASE-p3 FreeBSD amd64 mailboxes (Maildir), control files and indexes are on NFS (v3,tcp)
mail_nfs_storage = yes
lock_method = fcntl
[didn't touch the following]
# Mail index files also exist in NFS. Setting this to yes requires
# mmap_disable=yes and fsync_disable=no.
mail_nfs_index = yesserved by an Isilon s200 node (OneFS 6.5.5.22) procmail delivers in the same location through postfix-2.8.7
The filer shows *a lot* of such messages :
2013-08-02T14:12:29+02:00 <0.5> XXXX-10(id10) /boot/kernel.amd64/kernel: [lkf_delegate.c:2752](pid 46390="kt: dwt3")(tid=101282) dev_local_lkf_unlock(): no lock entry present to unlock for resource: 1:19d5:fdbe ;client: 0xa51cc3f444107
Corresponding file may be a message, a maildir, an index, ...
I can experience the same message with a simple fcntl C program which tries to unlock an NFS file without prior locking of it.
However, the problem occurs only on a FreeBSD client (I tried the old nfs client and the new (mount_newnfs), not on a 2.6.32-358.11.1.el6.x86_64 CentOS release 6.4 (Final) Linux release.
So my guess is that dovecot has some safety mechanism which tries to unlock locked files, maybe after some timeout and that, in the case of a an already unlocked file, the FreeBSD client sends the unlock RPC request to the server anyway whereas the linux client does not, noticing there isn't anything to unlock.
Can you help me explaining such a behavior ? Are those "unlock a file with no prior lock" made on purpose or is it a bug ? Would it be an application or a RPC bug ?
Can you think of another reason ?
Thanks
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Groupe Exploitation et Infrastructure