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

["Xin Zhao" <uszhaoxin@gmail.com>]

Hi, Bryan,

You gave several good points here. But can you be more specific: what
file system does not use unique inode? I am sorry for asking this dumb
question. But I am really eager to konw that.  Also, you mentioned
that some filesystems have no device number. I guess you are talking
about ramfs or similar file system, right? In our context, we don't
consider this possibility.

I know many people dislike to use inode number or device number in
file handle. NFS specs also avoid mentioning inodes, because it wants
to provide maximum interoperability. But our system is essentially a
NFS derived file system dedicated to sharing data across multiple VMs
in a single virtual server. So we can safely assume that both NFS
client and server are under our control, and no further
interoperabilitiy needs to be considered.

But your points seem to be valid as long as you can give more details
on "some file systems". ;-)

-x

On 8/10/06, Bryan Henderson <hbryan@us.ibm.com> wrote:
> >Can we make the following two conclusions?
> >1. In a single machine, inode+dev ID+i_generation can uniquely identify a
> file
>
> Without knowing the context, it's hard to say how picky you want to be,
> but here are some reasons the conclusion wouldn't be valid:
>
>   - In some filesystems, the inode number isn't as unique and stable as
> you'd like it to be.  In these, the inode
>     number has no internal use and is just something made up to satisfy
> stat().  And no, it doesn't satisfy all
>     requirements of stat(), but there's a compromise happening.  This
> compromise is especially visible in
>     filesystems that can have more than 4G filesystem objects, because
> inode numbers are 32 bits.
>
>     Consequently, NFS file handles for filesystem objects in these
> filesystems do not involve inode numbers.
>
>   - In some filesystems, there is no device number to speak of.  There's a
> made-up one to satisfy Linux structures
>     designed in the days that a filesystem lived on a disk, but you have
> to define some restrictions to consider
>     that device number usable to uniquely identify a file.
>
>     For this reason and others, Linux doesn't always use a device number
> in a file handle.  In general, it uses an
>     "export ID."
>
>   - In a traditional filesystem such as ext3, you have to define some
> restrictions in order for a device number to
>     help uniquely identify a file.  That's because in general, a
> filesystem's device number can change, especially
>     because a disk device's device number can change.
>
> >2. Given a stored file handle and an inode object received from the
> >server,  an NFS client can safely determine whether this inode
> >corresponds to the file handle by checking the inode+dev+i_generation.
>
> There's an unsettling theme in your questions that suggests that the NFS
> protocol involves inodes and inode numbers.  It doesn't, and I think
> assuming it does can lead you down some bad paths.  There is no inode
> number mentioned in NFS specs, and an NFS client doesn't know what the
> inode number of a file on the server is.  The individual server decides
> how to construct an NFS file handle.  In the earliest implementations of
> NFS servers, and continuing today in NFS serving of an ext3 filesystem,
> the server decides to use inode numbers and device numbers to construct
> the NFS file handle.  But it doesn't have to.
>
> --
> Bryan Henderson                     IBM Almaden Research Center
> San Jose CA                         Filesystems
>
>
>