On Tue, Mar 25, 2008 at 09:59:58AM -0700, Adam Schrotenboer wrote: > Adam Schrotenboer wrote: >> Neil Brown wrote: >>> On Wednesday March 12, jesper.juhl@xxxxxxxxx wrote: >>>> On 12/03/2008, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >>>>> What was the exported filesystem? >>>> XFS >>> >>> It's a bit of a long shot, but could you try mounting the XFS file >>> system with >>> -o ikeep >>> >>> and see if it makes a difference. >>> >>> When you have "ikeep", I can find the code that increments the >>> generation number between different uses of the one inode number. >>> >>> When you have "noikeep" (which I think is the default) it doesn't keep >>> the inode of disk when deleted and so (presumably) needs generate a >>> random generation number for each use. But I cannot find the code >>> that does that. I'm probably not looking in the right place, but I >>> don't think it can hurt to try "-o ikeep". >>> >>> NeilBrown >>> >> Ok, I've unmounted and remounted with that option enabled >> (/proc/mounts confirms it's enabled). We'll see what happens. > > Well, it's been almost 2 weeks (11 days anyhow) and I am not seeing > the nfs_update_inode message in the syslogs of any of our compute > servers. I need to talk to the various people who work with them to > verify, but it looks like this problem has been resolved. That's a workaround, at least, but it's unfortunate if a special mount option is required to get correct behavior for nfs exports. Is there anything we can do? --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
