On Sun, Nov 29, 2009 at 09:24:18AM +0100, Jesper Krogh wrote: > Hi. > > I'm seeing some random odd behaviour on my NFS clients. It is > not directly reproducible, but I have had users telling me about, but > until you hit stuff like this yourself .. you almost dont believe it. > > jk@bach:~$ ssh nfsserver ls -ltrah | grep blast-2.out > -rw-rw-r-- 1 jk jk 552K 2009-11-29 09:10 blast-2.out > jk@bach:~$ ls -tlrha | grep blast-2.out > jk@bach:~$ date > Sun Nov 29 09:17:14 CET 2009 > jk@bach:~$ stat blast-2.out > File: `blast-2.out' > Size: 564283 Blocks: 1112 IO Block: 1048576 regular file > Device: 18h/24d Inode: 139405089 Links: 1 > Access: (0664/-rw-rw-r--) Uid: ( 1000/ jk) Gid: ( 1000/ jk) > Access: 2009-11-29 09:07:34.000000000 +0100 > Modify: 2009-11-29 09:10:27.000000000 +0100 > Change: 2009-11-29 09:10:27.0000 > > So.. the file has been present for 7 minutes on the NFS-server (and any > client doing a fresh mount) but the client I'm sitting on is not having > the file in the directory listing, but if I explicitly ask for it.. its > there. > > Wether or not it has anything to do. The file has been written to the > NFS-server from another NFS-client. The server is running 2.6.31.5 and > the client that above was run on is 2.6.24-24 (Ubuntu Jaunty), the > client that wrote the file was running 2.6.29.1. I this v3 or v4? What's the exported filesystem? (ext3?) It's probably a timestamp resolution problem; if the directory was modified twice in the same second, the later change won't change the timestamp, and so the client may assume its cache is still good. Recent clients try a little harder to work around this. On the server side it should help to switch to a filesystem with better than 1-second timestamp resolution. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
