Re: Urgent help needed on an NFS question, please help!!!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]> wrote:
On Thursday August 10, [email protected] 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-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux