[linux-cifs-client] files disappearing randomly - kernel 2.6.27 cifs.ko 1.54 - VFS: No response for cmd 50

[Jeff Layton]

On Tue, 21 Apr 2009 16:47:47 +0200
Jodok Ole Muellers <muellejo at aschendorff.de> wrote:

> Hi,
> 
> I put a tcpdump of the problem here ftp://vam-emp.aschendorff.de/pub/prod-fs.cap
> This was running on the client:
> tcpdump -i bond0 -p -s 1500 -C1 -w prod-fs.cap port 445 or port 139 and host 10.2.1.155
> 
> 10.2.1.45  is client
> 10.2.1.155 is server
> 
> This is what i've done while capturing 
> 
> vam-uti3:/root # umount /data/dpa2msu/red-fs2
> vam-uti3:/root # mount /data/dpa2msu/red-fs2
> 
> vam-uti3:/root # cd /data/dpa2msu/red-fs2/bild/agentur/DPA
> 
> 
> vam-uti3:/data/dpa2msu/red-fs2/bild/agentur/DPA # ls -1 | wc -l
> 748
> vam-uti3:/data/dpa2msu/red-fs2/bild/agentur/DPA # ls -1 | wc -l
> 1348
> 
> vam-uti3:/data/dpa2msu/red-fs2/bild/agentur/DPA # ls -1 | wc -l
> 148
> 
> vam-uti3:/data/dpa2msu/red-fs2/bild/agentur/DPA # ls -1 | wc -l
> 298
> 
> vam-uti3:/data/dpa2msu/red-fs2/bild/agentur/DPA # ls -1 | wc -l
> 298
> vam-uti3:/data/dpa2msu/red-fs2/bild/agentur/DPA # ls -1 | wc -l
> 148
> 
> 
> Looks odd. 
> 148 seems to be a magic number somehow and shows up very often.
> 

Your server is consistently resetting the connection before the readdir
can finish. Here's one such example from the capture:

393   9.561300    10.2.1.45 -> 10.2.1.155   SMB Trans2 Request, FIND_NEXT2, Continue: 49D86C28.TXT
394   9.561502   10.2.1.155 -> 10.2.1.45    TCP microsoft-ds > 54108 [RST, ACK] Seq=27279 Ack=970 Win=0 Len=0
395   9.561572    10.2.1.45 -> 10.2.1.155   TCP 54110 > microsoft-ds [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=60843248 TSER=0 WS=6
396   9.561822   10.2.1.155 -> 10.2.1.45    TCP microsoft-ds > 54110 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
397   9.561845    10.2.1.45 -> 10.2.1.155   TCP 54110 > microsoft-ds [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=60843248 TSER=0
398   9.562238    10.2.1.45 -> 10.2.1.155   SMB Negotiate Protocol Request
399   9.562751   10.2.1.155 -> 10.2.1.45    SMB Negotiate Protocol Response

It's ultimately a server problem I think, but it would be good to
ascertain whether the kernel is returning an error here. Can you run
one of these failing "ls" calls inside of strace and tell whether the
readdir() or getdents() calls are returning an error?

-- 
Jeff Layton <jlayton at redhat.com>