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@xxxxxxxxxx> 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
-
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
