On Wed, March 26, 2008 6:09 am, J. Bruce Fields wrote: > 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? > I suggest taking it up with the XFS developers... Dear XFS developers. Adam (and Jesper, though that was some time ago) was having problems with an XFS filesystem that was exported via NFS. The client would occasionally report the message given in the subject line. Examining the NFS code suggested that the most likely explanation was that the generation number used in the file handle was the same every time that the inode number was re-used. Examining the XFS code suggested that when the 'ikeep' mount option was used, the generation number be explicitly incremented for each re-use, while without 'ikeep', no evidence of setting the generation number could be found. Maybe it defaults to zero. Experimental evidence suggests that setting 'ikeep' removes the symptom. Question: Is is possible that without 'ikeep', XFS does not even try to provide unique generation numbers? If this is the case, could it please be fixed. If it is not the case, please help me find the code responsible. Thanks, NeilBrown -- 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
