Trond, good news. I was able to narrow down the problem to purely the
client-side, probably dcache/readdir related, and I have a shell script that
deterministically triggers the problem each time for me (this is a FC6 image
under Vmware 6.0.1). Here's a short shell script which reliably triggers
the "lost files" problem -- I create a file via nfs2 on the client side, and
sometimes it doesn't show up in readdir, but it is there if you stat it
directly.
BTW, since this is a client-side bug, I also tried your last set of posted
client patches for Linus, but it didn't help.
Happy hunting. :-)
Erez.
##############################################################################
#!/bin/sh
dd if=/dev/zero of=/tmp/fs.$$.0 bs=1024k count=1 seek=100
losetup /dev/loop0 /tmp/fs.$$.0
mkfs -t ext2 -q /dev/loop0
mkdir -p /n/export/b0
mount -t ext2 /dev/loop0 /n/export/b0
exportfs -o no_root_squash,rw localhost:/n/export/b0
mkdir -p /n/client/b0
mount -t nfs -o nfsvers=2 localhost:/n/export/b0 /n/client/b0
count=0
while true; do
cfile="/n/client/b0/F.$count"
if touch $cfile ; then
echo $cfile created
else
echo "touch $cfile failed"
exit 1
fi
if `ls -1 /n/client/b0 | egrep -q F.$count'$'` ; then
:
else
echo "$cfile doesn't exist (but it should)"
ls -l /n/client/b0
ls -l /n/export/b0
stat $cfile
exit 1
fi
let count=count+1
done
##############################################################################
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
