On Mon, 2009-11-30 at 13:40 -0500, J. Bruce Fields wrote: > On Mon, Nov 30, 2009 at 07:30:55PM +0100, Jesper Krogh wrote: > > J. Bruce Fields wrote: > > >> 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?) > > > > v3 and 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. > > > > That's not nice.. but given the situation is may quite well be the > > problem. > > > > > Recent clients try a little harder to work around this. > > > > How recent and how much harder? > > There's the following. Looks like it was first included in 2.6.30. I > thought I remembered one or two other related changes, but perhaps the > others didn't make it in. There are also a bunch of attribute revalidation changesets that went into 2.6.28, and that improved the NFS client's ability to keep attributes up to date. Trond -- 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
