I found where the server checks the generation number. It's in fh_verify(). :) Many thanks for your help, Neil! -x On 8/10/06, Xin Zhao <uszhaoxin@xxxxxxxxx> wrote:
I think nfs_compare_fh() might do the file handle verification task. However, it is still possible that AFTER C1 gets a valid file handle, BUT BEFORE C1 sends out the getattr() request, C2 deletes file X and creates a different file X1 which has the same inode number. Looks like the server side must verify the generation number carried in the file handle. Unfortunately, I didn't find this code at the server side. Any further insight on this? Thanks, Xin On 8/10/06, Neil Brown <neilb@xxxxxxx> wrote: > On Thursday August 10, uszhaoxin@xxxxxxxxx wrote: > > I just ran into a problem about NFS. It might be a fundmental problem > > of my current work. So please help! > > > > I am wondering how NFS guarantees a client didn't get wrong file > > attributes. Consider the following scenario: > > > > Suppose we have an NFS server S and two clients C1 and C2. > > > > Now C1 needs to access the file attributes of file X, it first does > > lookup() to get the file handle of file X. > > > > After C1 gets X's file handle and before C1 issues the getattr() > > request, C2 cuts in. Now C2 deletes file X and creates a new file X1, > > which has different name but the same inode number and device ID as > > the nonexistent file X. > > > > When C1 issues getattr() with the old file handle, it may get file > > attribute on wrong file X1. Is this true? > > > > If not, how NFS avoid this problem? Please direct me to the code that > > verifies this. > > Generation numbers. > > When the filesystem creates a new file it assigns a random number > as the 'generation' number and stores that in the inode. > This gets included in the filehandle, and checked when the filehandle > lookup is done. > > Look for references to 'i_generation' in fs/ext3/* > > Other files systems may approach this slightly differently, but the > filesystem is responsible for providing a unique-over-time filehandle, > and 'generation number' is the 'standard' way of doing this. > > NeilBrown >
- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
