On Wed, 2008-05-28 at 09:59 -0400, J. Bruce Fields wrote: > On Wed, May 28, 2008 at 08:38:29AM +0300, Benny Halevy wrote: > > On May. 27, 2008, 22:13 +0300, Timo Sirainen <tss@xxxxxx> wrote: > > > I'd still like to understand why exactly this happens though. Maybe > > > there's a chance that this is just a bug in the current NFS > > > implementation so I could keep using my current code (which is > > > actually very difficult to break even with stress testing, so if this > > > doesn't get fixed on kernel side I'll probably just leave my code as > > > it is). I guess I'll start debugging the NFS code to find out what's > > > really going on. > > > > My guess would be that the new incarnation of the inode generates the > > same filehandle as the old one, not just the same inode number. > > That sounds like a server bug (either in the server itself, or the > filesystem it's exporting); the generation number is supposed to prevent > this. And if it happens, wouldn't the struct inode on NFS client be the same for both files then? I'm seeing different results for fstat() calls (just with the same st_ino).
Attachment:
signature.asc
Description: This is a digitally signed message part
