On Monday 26 November 2007 19:23:29 Gordon Messmer wrote:
Pavel Georgiev wrote:
To eliminate nfs race conditions I`ve turned the second mail server off,
so there is only one nfs client accessing the mailboxes. The nfs server
is a linux box as well, running Ubuntu 7.04, the underlying fs is
reiserfs and it runs on top of drbd (if this makes any differance).
It *shouldn't*, but I wouldn't be surprised if it did. I've never seen
that behavior. What I'd do is get a packet capture of the traffic
between the IMAP server and the NFS server, and analyze it with
ethereal. You can capture the packets with tcpdump from either host:
I tried exporting non-drdb share on the same server and it made no differance
so its not that.
For the test, I mounted the nfs share from another IP on the nfs server and
linked a mailbox to that mountpoint (in order to be able to isolate the
traffic to that mailbox in tcpdump). I captured the traffic and did strace of
the same time (with timestamps in order to match the nfs traffic to the
strace).
You can see the two logs here:
http://0101.netclime.net/tcpdump.log (3MB)
http://0101.netclime.net/strace.log (14MB)
but from what I see I keep having nfs traffic during the loop.
I also tried mounding the nfs server over udp but it made no differance. Here
is my current /proc/mounts:
xxxx:xxxxx /xxxx nfs
rw,noatime,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=11,retrans=2,sec=sys,addr=xxxxxx
0 0
imap# tcpdump -s0 -o /tmp/nfs.chatter host <nfs hostname>
Start the dump before you log in to IMAP, and stop it with ctrl+c a few
seconds after you've logged in. You should be able to use ethereal to
check whether or not the NFS server is reporting those files in new/
after they've been moved. If you're not sure how to do it, you can send
me the packet capture and I'll help you figure it out.
9 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Courier Imap + NF...
.log
